File Manager

003 File Manager

Current Path: /usr/src/contrib/llvm-project/llvm/include/llvm/Support

usr / src / contrib / llvm-project / llvm / include / llvm / Support /

📁 ..
📄 AArch64TargetParser.def(12.01 KB)
📄 AArch64TargetParser.h(4.89 KB)
📄 AMDGPUMetadata.h(17.98 KB)
📄 AMDHSAKernelDescriptor.h(7.63 KB)
📄 ARMAttributeParser.h(3.2 KB)
📄 ARMBuildAttributes.h(8.6 KB)
📄 ARMEHABI.h(3.72 KB)
📄 ARMTargetParser.def(18.94 KB)
📄 ARMTargetParser.h(8.76 KB)
📄 ARMWinEH.h(18.27 KB)
📄 AlignOf.h(1.56 KB)
📄 Alignment.h(12.95 KB)
📄 Allocator.h(16.54 KB)
📄 AllocatorBase.h(3.87 KB)
📄 ArrayRecycler.h(4.78 KB)
📄 Atomic.h(1.09 KB)
📄 AtomicOrdering.h(6.01 KB)
📄 Automaton.h(9.64 KB)
📄 Base64.h(1.84 KB)
📄 BinaryByteStream.h(9.14 KB)
📄 BinaryItemStream.h(3.63 KB)
📄 BinaryStream.h(3.75 KB)
📄 BinaryStreamArray.h(12.46 KB)
📄 BinaryStreamError.h(1.29 KB)
📄 BinaryStreamReader.h(11.01 KB)
📄 BinaryStreamRef.h(10.09 KB)
📄 BinaryStreamWriter.h(7.79 KB)
📄 BlockFrequency.h(2.41 KB)
📄 BranchProbability.h(7.92 KB)
📄 BuryPointer.h(1.03 KB)
📄 CBindingWrapping.h(1.86 KB)
📄 CFGDiff.h(9.95 KB)
📄 CFGUpdate.h(4.12 KB)
📄 COM.h(1004 B)
📄 CRC.h(1.63 KB)
📄 CachePruning.h(3.5 KB)
📄 Capacity.h(972 B)
📄 Casting.h(13.92 KB)
📄 CheckedArithmetic.h(3.71 KB)
📄 Chrono.h(5.78 KB)
📄 CodeGen.h(1.96 KB)
📄 CodeGenCoverage.h(1.18 KB)
📄 CommandLine.h(71.22 KB)
📄 Compiler.h(19.5 KB)
📄 Compression.h(1.39 KB)
📄 ConvertUTF.h(11.4 KB)
📄 CrashRecoveryContext.h(9.26 KB)
📄 DJB.h(1.05 KB)
📄 DOTGraphTraits.h(5.58 KB)
📄 DataExtractor.h(30.28 KB)
📄 DataTypes.h(775 B)
📄 Debug.h(4.7 KB)
📄 DebugCounter.h(7.01 KB)
📄 DynamicLibrary.h(5.77 KB)
📄 ELFAttributeParser.h(2.22 KB)
📄 ELFAttributes.h(1.02 KB)
📄 Endian.h(14.28 KB)
📄 EndianStream.h(1.93 KB)
📄 Errc.h(3.8 KB)
📄 Errno.h(1.45 KB)
📄 Error.h(43.82 KB)
📄 ErrorHandling.h(6.39 KB)
📄 ErrorOr.h(7.48 KB)
📄 ExtensibleRTTI.h(4.02 KB)
📄 FileCheck.h(6.69 KB)
📄 FileCollector.h(3.74 KB)
📄 FileOutputBuffer.h(3.36 KB)
📄 FileSystem.h(53.03 KB)
📄 FileUtilities.h(3.83 KB)
📄 Format.h(9.45 KB)
📄 FormatAdapters.h(3.38 KB)
📄 FormatCommon.h(2.05 KB)
📄 FormatProviders.h(15.27 KB)
📄 FormatVariadic.h(9.88 KB)
📄 FormatVariadicDetails.h(5.3 KB)
📄 FormattedStream.h(6.42 KB)
📄 GenericDomTree.h(30.89 KB)
📄 GenericDomTreeConstruction.h(63.42 KB)
📄 GenericIteratedDominanceFrontier.h(7.31 KB)
📄 GlobPattern.h(1.35 KB)
📄 GraphWriter.h(11.79 KB)
📄 Host.h(2.68 KB)
📄 InitLLVM.h(1.79 KB)
📄 ItaniumManglingCanonicalizer.h(3.17 KB)
📄 JSON.h(28.25 KB)
📄 KnownBits.h(8.35 KB)
📄 LEB128.h(5.74 KB)
📄 LineIterator.h(2.62 KB)
📄 Locale.h(223 B)
📄 LockFileManager.h(3.13 KB)
📄 LowLevelTypeImpl.h(11.94 KB)
📄 MD5.h(3.39 KB)
📄 MSVCErrorWorkarounds.h(2.62 KB)
📄 MachineValueType.h(42.37 KB)
📄 ManagedStatic.h(4.21 KB)
📄 MathExtras.h(32.81 KB)
📄 MemAlloc.h(3.21 KB)
📄 Memory.h(6.94 KB)
📄 MemoryBuffer.h(10.98 KB)
📄 MipsABIFlags.h(3.92 KB)
📄 Mutex.h(2.14 KB)
📄 NativeFormatting.h(1.64 KB)
📄 OnDiskHashTable.h(21.97 KB)
📄 OptimizedStructLayout.h(5.89 KB)
📄 Parallel.h(5.99 KB)
📄 Path.h(15.6 KB)
📄 PluginLoader.h(1.29 KB)
📄 PointerLikeTypeTraits.h(5.69 KB)
📄 PrettyStackTrace.h(4.45 KB)
📄 Printable.h(1.5 KB)
📄 Process.h(9.31 KB)
📄 Program.h(10.35 KB)
📄 RISCVAttributeParser.h(1.15 KB)
📄 RISCVAttributes.h(1.2 KB)
📄 RISCVTargetParser.def(446 B)
📄 RWMutex.h(5.65 KB)
📄 RandomNumberGenerator.h(2.29 KB)
📄 Recycler.h(3.47 KB)
📄 RecyclingAllocator.h(2.38 KB)
📄 Regex.h(4.37 KB)
📄 Registry.h(5.14 KB)
📄 ReverseIteration.h(360 B)
📄 SHA1.h(2.37 KB)
📄 SMLoc.h(1.78 KB)
📄 SMTAPI.h(16.33 KB)
📄 SaveAndRestore.h(1.02 KB)
📄 ScaledNumber.h(30.65 KB)
📄 ScopedPrinter.h(11.39 KB)
📄 Signals.h(5.22 KB)
📄 Signposts.h(1.29 KB)
📄 SmallVectorMemoryBuffer.h(2.28 KB)
📁 Solaris
📄 SourceMgr.h(10.37 KB)
📄 SpecialCaseList.h(6.01 KB)
📄 StringSaver.h(1.94 KB)
📄 SuffixTree.h(13.15 KB)
📄 SwapByteOrder.h(4.8 KB)
📄 SymbolRemappingReader.h(4.36 KB)
📄 SystemUtils.h(1.02 KB)
📄 TarWriter.h(941 B)
📄 TargetOpcodes.def(22.01 KB)
📄 TargetParser.h(4.08 KB)
📄 TargetRegistry.h(46.87 KB)
📄 TargetSelect.h(6.2 KB)
📄 TaskQueue.h(4.24 KB)
📄 ThreadLocal.h(2.08 KB)
📄 ThreadPool.h(3.44 KB)
📄 Threading.h(10.62 KB)
📄 TimeProfiler.h(3.46 KB)
📄 Timer.h(8.93 KB)
📄 ToolOutputFile.h(2.24 KB)
📄 TrailingObjects.h(15.19 KB)
📄 TrigramIndex.h(2.84 KB)
📄 TypeName.h(2.13 KB)
📄 TypeSize.h(8.53 KB)
📄 Unicode.h(2.5 KB)
📄 UnicodeCharRanges.h(3.27 KB)
📄 Valgrind.h(1.16 KB)
📄 VersionTuple.h(5.22 KB)
📄 VirtualFileSystem.h(28.28 KB)
📄 Watchdog.h(1.15 KB)
📄 Win64EH.h(4.82 KB)
📁 Windows
📄 WindowsError.h(541 B)
📄 WithColor.h(4.64 KB)
📄 X86DisassemblerDecoderCommon.h(29.39 KB)
📄 X86TargetParser.def(8.21 KB)
📄 X86TargetParser.h(3.57 KB)
📄 YAMLParser.h(16.29 KB)
📄 YAMLTraits.h(67.62 KB)
📄 circular_raw_ostream.h(4.97 KB)
📄 raw_os_ostream.h(1.29 KB)
📄 raw_ostream.h(20.82 KB)
📄 raw_sha1_ostream.h(1.29 KB)
📄 thread.h(1.33 KB)
📄 type_traits.h(6.75 KB)
📄 xxhash.h(1.92 KB)

Editing: OptimizedStructLayout.h

//===-- OptimizedStructLayout.h - Struct layout algorithm ---------*- C++ -*-=//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
///
/// This file provides an interface for laying out a sequence of fields
/// as a struct in a way that attempts to minimizes the total space
/// requirements of the struct while still satisfying the layout
/// requirements of the individual fields.  The resulting layout may be
/// substantially more compact than simply laying out the fields in their
/// original order.
///
/// Fields may be pre-assigned fixed offsets.  They may also be given sizes
/// that are not multiples of their alignments.  There is no currently no
/// way to describe that a field has interior padding that other fields may
/// be allocated into.
///
/// This algorithm does not claim to be "optimal" for several reasons:
///
/// - First, it does not guarantee that the result is minimal in size.
///   There is no known efficient algoorithm to achieve minimality for
///   unrestricted inputs.  Nonetheless, this algorithm 
///
/// - Second, there are other ways that a struct layout could be optimized
///   besides space usage, such as locality.  This layout may have a mixed
///   impact on locality: less overall memory may be used, but adjacent
///   fields in the original array may be moved further from one another.
///
//===----------------------------------------------------------------------===//

#ifndef LLVM_SUPPORT_OPTIMIZEDSTRUCTLAYOUT_H
#define LLVM_SUPPORT_OPTIMIZEDSTRUCTLAYOUT_H

#include "llvm/Support/Alignment.h"
#include "llvm/ADT/ArrayRef.h"
#include <utility>

namespace llvm {

/// A field in a structure.
struct OptimizedStructLayoutField {
  /// A special value for Offset indicating that the field can be moved
  /// anywhere.
  static constexpr uint64_t FlexibleOffset = ~(uint64_t)0;

OptimizedStructLayoutField(const void *Id, uint64_t Size, Align Alignment,
                             uint64_t FixedOffset = FlexibleOffset)
      : Offset(FixedOffset), Size(Size), Id(Id), Alignment(Alignment) {
    assert(Size > 0 && "adding an empty field to the layout");
  }

/// The offset of this field in the final layout.  If this is
  /// initialized to FlexibleOffset, layout will overwrite it with
  /// the assigned offset of the field.
  uint64_t Offset;

/// The required size of this field in bytes.  Does not have to be
  /// a multiple of Alignment.  Must be non-zero.
  uint64_t Size;

/// A opaque value which uniquely identifies this field.
  const void *Id;

/// Private scratch space for the algorithm.  The implementation
  /// must treat this as uninitialized memory on entry.
  void *Scratch;

/// The required alignment of this field.
  Align Alignment;

/// Return true if this field has been assigned a fixed offset.
  /// After layout, this will be true of all the fields.
  bool hasFixedOffset() const {
    return (Offset != FlexibleOffset);
  }

/// Given that this field has a fixed offset, return the offset
  /// of the first byte following it.
  uint64_t getEndOffset() const {
    assert(hasFixedOffset());
    return Offset + Size;
  }
};

/// Compute a layout for a struct containing the given fields, making a
/// best-effort attempt to minimize the amount of space required.
///
/// Two features are supported which require a more careful solution
/// than the well-known "sort by decreasing alignment" solution:
///
/// - Fields may be assigned a fixed offset in the layout.  If there are
///   gaps among the fixed-offset fields, the algorithm may attempt
///   to allocate flexible-offset fields into those gaps.  If that's
///   undesirable, the caller should "block out" those gaps by e.g.
///   just creating a single fixed-offset field that represents the
///   entire "header".
///
/// - The size of a field is not required to be a multiple of, or even
///   greater than, the field's required alignment.  The only constraint
///   on fields is that they must not be zero-sized.
///
/// To simplify the implementation, any fixed-offset fields in the
/// layout must appear at the start of the field array, and they must
/// be ordered by increasing offset.
///
/// The algorithm will produce a guaranteed-minimal layout with no
/// interior padding in the following "C-style" case:
///
/// - every field's size is a multiple of its required alignment and
/// - either no fields have initially fixed offsets, or the fixed-offset
///   fields have no interior padding and end at an offset that is at
///   least as aligned as all the flexible-offset fields.
///
/// Otherwise, while the algorithm will make a best-effort attempt to
/// avoid padding, it cannot guarantee a minimal layout, as there is
/// no known efficient algorithm for doing so.
///
/// The layout produced by this algorithm may not be stable across LLVM
/// releases.  Do not use this anywhere where ABI stability is required.
///
/// Flexible-offset fields with the same size and alignment will be ordered
/// the same way they were in the initial array.  Otherwise the current
/// algorithm makes no effort to preserve the initial order of
/// flexible-offset fields.
///
/// On return, all fields will have been assigned a fixed offset, and the
/// array will be sorted in order of ascending offsets.  Note that this
/// means that the fixed-offset fields may no longer form a strict prefix
/// if there's any padding before they end.
///
/// The return value is the total size of the struct and its required
/// alignment.  Note that the total size is not rounded up to a multiple
/// of the required alignment; clients which require this can do so easily.
std::pair<uint64_t, Align> performOptimizedStructLayout(
                        MutableArrayRef<OptimizedStructLayoutField> Fields);

} // namespace llvm

#endif

003 File Manager

Editing: OptimizedStructLayout.h

Upload File

Create Folder