search for: getorcreate

Hi, Consider ConstantUniqueMap::getOrCreate() (in lib/VMCore/ConstantsContext.h): /// getOrCreate - Return the specified constant from the map, creating it if /// necessary. ConstantClass *getOrCreate(const TypeClass *Ty, ValRefType V) { MapKey Lookup(Ty, V); ConstantClass* Result = 0; ... For array (or struct or vector)...

...stant *ConstantArray::get(const ArrayType *Ty, const std::vector<Constant*> &V) { // If this is an all-zero array, return a ConstantAggregateZero object if (!V.empty()) { Constant *C = V[0]; if (!C->isNullValue()) return ArrayConstants->getOrCreate(Ty, V); for (unsigned i = 1, e = V.size(); i != e; ++i) if (V[i] != C) return ArrayConstants->getOrCreate(Ty, V); } return ConstantAggregateZero::get(Ty); } This seems wrong to me, and it's causing a problem in Objective-C, which requires that an empty string be placed...

On Jun 24, 2011, at 8:28 AM, Jay Foad wrote: > Hi, > > Consider ConstantUniqueMap::getOrCreate() (in lib/VMCore/ConstantsContext.h): > > /// getOrCreate - Return the specified constant from the map, creating it if > /// necessary. > ConstantClass *getOrCreate(const TypeClass *Ty, ValRefType V) { > MapKey Lookup(Ty, V); > ConstantClass* Result = 0; > ... >...

...base, but we need to either 1> keep the worklist or 2> remove the worklist and modify the code base to make the assumption true, right? If we are going to make the assumption true, any suggestion on how to fix the above cases? One possibility is to find the correct CU in DwarfDebug, and call getOrCreate on the correct CU. In your above example, if a later CU wants to add a member function to an earlier CU, we find the earlier CU in DwarfDebug by going through the context chain of the member function, and then call getOrCreate on the earlier CU. So we can try to make the statement "a CU only...

...we are going to make the assumption true, any suggestion on how to fix > the above cases? > I don't know if the above cases are problems. Have you written and verified any of the test cases I've described? > One possibility is to find the correct CU in DwarfDebug, and call > getOrCreate on the correct CU. > In your above example, if a later CU wants to add a member function to an > earlier CU, we find the earlier CU in DwarfDebug by going through the > context chain of the member function, and then call getOrCreate on the > earlier CU. > > So we can try to make t...

...debugging symbols enabled, and this code has worked. However, on the Release+Asserts version, the third line results in a segmentation fault. The backtrace for the error, up to the method I'm working on, is as follows: // signal handling... #4 0x00005556e48d6120 llvm::ReplaceableMetadataImpl::getOrCreate(llvm::Metadata&) (/home/sjessu/build-no-debug/bin/clang-10+0x2787120) #5 0x00005556e48db8c2 llvm::MetadataTracking::track(void*, llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Metadata*>) (/home/sjessu/build-no-debug/bin/clang-10+0x278c8c2) #6 0x00005556e48dbc12 l...

...rue, any suggestion on how to fix >> the above cases? >> > > I don't know if the above cases are problems. Have you written and > verified any of the test cases I've described? > > >> One possibility is to find the correct CU in DwarfDebug, and call >> getOrCreate on the correct CU. >> In your above example, if a later CU wants to add a member function to an >> earlier CU, we find the earlier CU in DwarfDebug by going through the >> context chain of the member function, and then call getOrCreate on the >> earlier CU. >> >>...

...e the DIEs are constructed by CUs and just added >> to the appropriate cache (either CU-local, or cross-CU), they're never >> constructed outside of a CU, are they? >> > I am referring to the "new DIE" in DwarfDebug.cpp, and saying that we > should instead call getOrCreate function on a CU. > Perhaps I'll need to go back and check your patch, but generally, I tend to think we should be calling into a CU to build anything ratehr than doing it 'raw' in DwarfDebug.cpp. > > >> >> >>> How much effort is required to make sure th...

...efore. There are a lots of parser extensions that creates the symbols. And in each place we need insert add its location info. I also found that MCContext has several create symbols methods, but all these methods uses CreateSymbol private method. So I see two possible ways here: 1. To aggregate all GetOrCreate-like symbol methods inside the AsmParser. So all asm parser extension like a COFFAsmParser should use aggregated methods instead of MCContext ones. And inside the aggregated methods we can add symbol location info. 2. Add create-symbol event to the MCContext. So each time when symbol will created b...

Hi everybody. I found that there are some problems with symbol location in AsmParser. 1. We need to know where symbol was declared. 2. We need to know where symbol was defined first time. There are two ways: 1. Add helper table to the parser with additional symbol info. But it takes additional memory consumption. 2. Add user tag (void*) for MCSymbol object. As I understood MCSymbol can live

...However, on the Release+Asserts >> version, the third line results in a segmentation fault. The backtrace for >> the error, up to the method I'm working on, is as follows: >> >> // signal handling... >> #4 0x00005556e48d6120 >> llvm::ReplaceableMetadataImpl::getOrCreate(llvm::Metadata&) >> (/home/sjessu/build-no-debug/bin/clang-10+0x2787120) >> #5 0x00005556e48db8c2 llvm::MetadataTracking::track(void*, >> llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*, >> llvm::Metadata*>) (/home/sjessu/build-no-debug/bin/clang-10...

...t;> fix the above cases? >>> >> >> I don't know if the above cases are problems. Have you written and >> verified any of the test cases I've described? >> >> >>> One possibility is to find the correct CU in DwarfDebug, and call >>> getOrCreate on the correct CU. >>> In your above example, if a later CU wants to add a member function to >>> an earlier CU, we find the earlier CU in DwarfDebug by going through the >>> context chain of the member function, and then call getOrCreate on the >>> earlier CU. &...

...nstant*, std::allocator<llvm::Constant*> > > const&) ( Constants.cpp:1181) ==10132== by 0x84D1134: (anonymous namespace)::ValueMap<std::pair<unsigned, std::vector<llvm::Constant*, std::allocator<llvm::Constant*> > >, llvm::Type, llvm::ConstantExpr, false>::getOrCreate(llvm::Type const*, std::pair<unsigned, std::vector<llvm::Constant*, std::allocator<llvm::Constant*> > > const&) ( Constants.cpp:639) ==10132== by 0x8494CA1: llvm::ConstantExpr::getCast(llvm::Constant*, llvm::Type const*) (Constants.cpp:1262) ==10132== by 0x83E23D9: llvm:...

...t;> fix the above cases? >>> >> >> I don't know if the above cases are problems. Have you written and >> verified any of the test cases I've described? >> >> >>> One possibility is to find the correct CU in DwarfDebug, and call >>> getOrCreate on the correct CU. >>> In your above example, if a later CU wants to add a member function to >>> an earlier CU, we find the earlier CU in DwarfDebug by going through the >>> context chain of the member function, and then call getOrCreate on the >>> earlier CU. &...

As of late I see these warnings: llvm[1]: Compiling Constants.cpp for Release build /usr/include/c++/4.0.0/bits/stl_pair.h: In member function 'ConstantClass* llvm::ValueMap<ValType, TypeClass, ConstantClass, HasLargeKey>::getOrCreate(const TypeClass*, const ValType&) [with ValType = <unnamed>::ExprMapKeyType, TypeClass = llvm::Type, ConstantClass = llvm::ConstantExpr, bool HasLargeKey = false]': /usr/include/c++/4.0.0/bits/stl_pair.h:97: warning: control may reach end of non-void function 'bool<unname...

Hi, Here is the follow on patch for this problem. Please apply this from the top of the tree and rebuild. -------------- next part -------------- A non-text attachment was scrubbed... Name: op Type: application/octet-stream Size: 2548 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060315/eee8a766/attachment.obj> -------------- next part

...stant*> > >::create (Ty=0x8b25730, V=@0xbf8adef0) at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:531 #5 0x087e6eaf in (anonymous namespace)::ValueMap<std::vector<llvm::Constant*, std::allocator<llvm::Constant*> >, llvm::StructType, llvm::ConstantStruct, true>::getOrCreate (this=0x8af8060, Ty=0x8b25730, V=@0xbf8adef0) at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:624 #6 0x087aa821 in llvm::ConstantStruct::get (Ty=0x8b25730, V=@0xbf8adef0) at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:994 #7 0x08714182 in llvm::DISerializer::Serialize (this=0...

On Wed, 15 Mar 2006, Vladimir Prus wrote: >> Please give it a try and let me know if it works any better for you! > > Here we go: Wow, you are good at finding problems! Thanks! > -fvisibility=hidden -DHIDE_EXPORTS > -c ../../2006-03-14-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_fixunsxfdi.o > cc1: /space/p2/ghost/build/llvm-cvs/include/llvm/Instructions.h:72: void >

...; Even with your change the DIEs are constructed by CUs and just added to the > appropriate cache (either CU-local, or cross-CU), they're never constructed > outside of a CU, are they? > I am referring to the "new DIE" in DwarfDebug.cpp, and saying that we should instead call getOrCreate function on a CU. > > >> How much effort is required to make sure these assumptions are true? We >> also should have the corresponding assertions to make sure the assumptions >> are not violated. >> > > Personally, I'm OK saying "this is the intended d...

On Tue, Oct 15, 2013 at 4:59 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 2:24 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 1:56 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at