search for: typeindex

...> >> + CodeViewTypes : DICodeViewTypes >> >> >> >> DICodeViewTypes >> >> + TypeRecords : MDString[] >> >> + UDTSymbols : DICodeViewUDT[] >> >> >> >> DICodeViewUDT >> >> + Name : MDString >> >> + TypeIndex : uint32_t >> >> >> >> DIVariable >> >> + *existing fields* >> >> + TypeIndex : uint32_t >> >> >> >> DISubprogram >> >> + *existing fields* >> >> + TypeIndex : uint32_t >> >> The existing DIC...

...esumably your JIT code will reuse some of the same types (perhaps, > std::string for example) as your non-jitted code. Your jitted symbol > records in the object file (for example, a local variable of type > std::string in your jitted code) will refer to the type for std;:string by > a TypeIndex, and your original PDB will also refer to std::string by a > different TypeIndex. > > In LLD, when we merge in types and symbols from each object file, we keep > a hash table of which types have already been seen, so that if we see the > same type again, we can just use the TypeIndex...

...only the back-end knows the code addresses, data addresses, and stack frame layouts. Representation of CodeView in LLVM IR DICompileUnit + existing fields + CodeViewTypes : DICodeViewTypes DICodeViewTypes + TypeRecords : MDString[] + UDTSymbols : DICodeViewUDT[] DICodeViewUDT + Name : MDString + TypeIndex : uint32_t DIVariable + existing fields + TypeIndex : uint32_t DISubprogram + existing fields + TypeIndex : uint32_t The existing DICompileUnit node will have a new operand named CodeViewTypes, which points to the new DICodeViewTypes node that describes the CodeView type information for the compi...

Ok I see.. what do you mean by “making sure to de-duplicate records as necessary” ? Le jeu. 17 janv. 2019 à 19:09, Zachary Turner <zturner at google.com> a écrit : > It's possible in theory to support incremental updates to a PDB (the file > format is designed specifically with that in mind). But this functionality > was never added to the PDB library since lld doesn't

...e some of the same types (perhaps, >>> std::string for example) as your non-jitted code. Your jitted symbol >>> records in the object file (for example, a local variable of type >>> std::string in your jitted code) will refer to the type for std;:string by >>> a TypeIndex, and your original PDB will also refer to std::string by a >>> different TypeIndex. >>> >>> In LLD, when we merge in types and symbols from each object file, we >>> keep a hash table of which types have already been seen, so that if we see >>> the same t...

...ing the bits > needed by MC don't depend on Object)? Any suggestions? Sink it into > BinaryFormat or name a new library? > > (it's quite a few headers by the looks of it: CodeView.h, Line.h, > SymbolRecord.h, CodeViewTypes.def, CodeViewSymbols.def, > CodeViewRegisters.def, TypeIndex.h, CVRecord.h, CodeViewError.h, > RecordSerialization.h - maybe some of those aren't needed, if they're > excessive includes or the like (they tend to seep in all over the place)) > > >> >> >>> include/llvm/Object/COFF.h includes >>>> include/llv...

...gt;>>>>>> symbol records in the object file (for example, a local variable of type >>>>>>>>>>>>>>> std::string in your jitted code) will refer to the type for std;:string by >>>>>>>>>>>>>>> a TypeIndex, and your original PDB will also refer to std::string by a >>>>>>>>>>>>>>> different TypeIndex. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In LLD, when we merge in types and s...

...up DebugInfo/CodeView (assuming the bits needed by MC don't depend on Object)? Any suggestions? Sink it into BinaryFormat or name a new library? (it's quite a few headers by the looks of it: CodeView.h, Line.h, SymbolRecord.h, CodeViewTypes.def, CodeViewSymbols.def, CodeViewRegisters.def, TypeIndex.h, CVRecord.h, CodeViewError.h, RecordSerialization.h - maybe some of those aren't needed, if they're excessive includes or the like (they tend to seep in all over the place)) > > >> include/llvm/Object/COFF.h includes >>> include/llvm/DebugInfo/CodeView/CVDebugRecord...

...> jitted symbol records in the object file (for example, a local variable of >>>>>>>>>>>>>>>>> type std::string in your jitted code) will refer to the type for >>>>>>>>>>>>>>>>> std;:string by a TypeIndex, and your original PDB will also refer to >>>>>>>>>>>>>>>>> std::string by a different TypeIndex. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In LLD, when...

...eded by MC don't depend on Object)? Any suggestions? Sink it into >> BinaryFormat or name a new library? >> >> (it's quite a few headers by the looks of it: CodeView.h, Line.h, >> SymbolRecord.h, CodeViewTypes.def, CodeViewSymbols.def, >> CodeViewRegisters.def, TypeIndex.h, CVRecord.h, CodeViewError.h, >> RecordSerialization.h - maybe some of those aren't needed, if they're >> excessive includes or the like (they tend to seep in all over the place)) >> >> >>> >>> >>>> include/llvm/Object/COFF.h includes...

On Thu, Mar 22, 2018 at 12:55 PM Reid Kleckner <rnk at google.com> wrote: > On Wed, Mar 21, 2018 at 11:31 AM David Blaikie <dblaikie at gmail.com> wrote: > >> I'm looking at fixing some layering violations in LLVM & came across a >> few in the CodeView handling, specifically: >> >> lib/MC/MCCodeView includes several llvm/DebugInfo/CodeView headers

...depend on Object)? Any suggestions? Sink it into >>> BinaryFormat or name a new library? >>> >>> (it's quite a few headers by the looks of it: CodeView.h, Line.h, >>> SymbolRecord.h, CodeViewTypes.def, CodeViewSymbols.def, >>> CodeViewRegisters.def, TypeIndex.h, CVRecord.h, CodeViewError.h, >>> RecordSerialization.h - maybe some of those aren't needed, if they're >>> excessive includes or the like (they tend to seep in all over the place)) >>> >>> >>>> >>>> >>>>> include/...

...essage methodCallMessage) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage) at System.Resources.ResourceReader.DeserializeObject(Int32 typeIndex) at System.Resources.ResourceReader.LoadObjectV2(Int32 pos, ResourceTypeCode& typeCode) at System.Resources.ResourceReader.LoadObject(Int32 pos) at System.Resources.ResourceReader.ResourceEnumerator.get_Entry() at System.Resources.ResourceReader.ResourceEnumerator.get_Current() a...

...ts/out-arm/include/c++/v1/./ostream > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./tuple > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./__config > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./typeindex > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./regex > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./ext > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./ext/hash_map > -- Installing: > /h...

On 10/3/14 10:16 AM, Dan Albert wrote: >> >> I try to build libc++ and libc++abi for host x86_64(linux) and target >> arm(linux) but fail. >> > > Failing in what way? If this isn't working out of the box, we've done > something wrong. Yeah, it would help to know more specifics about where you're getting stuck. > > jroelofs might know more... For

...8 0.000% 38 16 0.000% 39 13 0.000% 40 13 0.000% 41 9 0.000% 42 6 0.000% 43 5 0.000% 44 5 0.000% 45 3 0.000% 46 3 0.000% 47 3 0.000% 48 2 0.000% 49 2 0.000% 50 2 0.000% 51 1 0.000% 205938071 Now if you split the key (64-bit ghash) from the value (32-bit TypeIndex), you would double the cache misses, right? The hashtable can quickly get pretty big, it is very unlikely that you would hit the same cache line in the L1d on the next record (and maybe L2). Could you please explain your algorithm more in detail? llvm-lib is llvm-ar in disguise ;-) From: Leonar...

This could be ICF. There were lots of issues with ICF on ARM64, but they are not inherently ARM64-specific, they just come up there more often. See https://reviews.llvm.org/D56986 which fixes that. Easiest thing is always to profile or add /time to see what's slow. On Wed, Feb 27, 2019 at 6:30 AM Leonardo Santagada <santagada at gmail.com> wrote: > Anyone would know why lld takes