similar to: [LLVMdev] inefficiencies in ConstantUniqueMap ?

Displaying 20 results from an estimated 400 matches similar to: "[LLVMdev] inefficiencies in ConstantUniqueMap ?"

2011 Jun 24
0
[LLVMdev] inefficiencies in ConstantUniqueMap ?
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; > ...
2008 Jun 11
0
[LLVMdev] Warnings
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,
2005 May 03
2
[LLVMdev] VC++ build broken
The recently added code: static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty, -INFINITY); if (V2->isNullValue()) return 0; BuiltinType R = (BuiltinType)V1->getValue() / (BuiltinType)V2->getValue(); return
2005 May 03
0
[LLVMdev] VC++ build broken
On Mon, 2 May 2005, Jeff Cohen wrote: > The recently added code: > static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { > if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); > if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty, -INFINITY); > if (V2->isNullValue()) return 0; > BuiltinType R =
2005 May 03
2
[LLVMdev] VC++ build broken
Yes, that will work. I'll make the change. Chris Lattner wrote: > On Mon, 2 May 2005, Jeff Cohen wrote: > >> The recently added code: >> static Constant *Div(const ConstantClass *V1, const ConstantClass *V2) { >> if (V2->isExactlyValue(0.0)) return ConstantClass::get(*Ty, INFINITY); >> if (V2->isExactlyValue(-0.0)) return ConstantClass::get(*Ty,
2011 Jun 30
0
[LLVMdev] inefficiencies in ConstantUniqueMap ?
On 30 June 2011 14:07, Duncan Sands <baldrick at free.fr> wrote: > Hi Jay, > >> As I understand it, PATypeHolder, OpaqueType and the Module's >> TypeSymbolTable are gone. Instead, StructTypes can optionally be >> named, and if they are then: >> >> - they use name equivalence instead of structural equivalence. >> - you can create them without any
2011 Jun 30
0
[LLVMdev] inefficiencies in ConstantUniqueMap ?
>>> [...] why not to a struct without a name? >> >> This would imply that you were starting with a struct with no name and >> no fields, which is not something you can create in C: >> >> struct; // this isn't a C type! > > I see structs with fields but without names come flying out of gcc for C++ > code > all the time. That's fine; in C
2011 Jun 30
0
[LLVMdev] inefficiencies in ConstantUniqueMap ?
I'll have another go then! > I find this distinction between structs with names and structs without > names strange.  Why is a name relevant to anything?  If you can add fields > to a struct with a name [...] This corresponds to the following C constructs: struct S; // create struct with name but no fields ... struct S { int i, j; } // add fields to named struct > [...] why not
2011 Jun 30
1
[LLVMdev] inefficiencies in ConstantUniqueMap ?
On Jun 30, 2011, at 5:38 AM, Jay Foad wrote: > In case anyone's interested, here's my work-in-progress patch for > clang. (Note that it's against a slightly old clang tree, because the > llvm type-system-rewrite branch hasn't had a merge from trunk > recently; and you also need the attached llvm patchlet to make it all > build.) > I'm not 100% satisfied with
2011 Jun 25
0
[LLVMdev] inefficiencies in ConstantUniqueMap ?
On 25 June 2011 13:00, Duncan Sands <baldrick at free.fr> wrote: >> 3. Clang/dragonegg need to adapt to the new API (help appreciated!) > > what needs to be done exactly? Background info: http://www.nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt As I understand it, PATypeHolder, OpaqueType and the Module's TypeSymbolTable are gone. Instead, StructTypes can optionally be
2011 Jun 30
2
[LLVMdev] inefficiencies in ConstantUniqueMap ?
Hi Jay, > I'll have another go then! thanks! >> I find this distinction between structs with names and structs without >> names strange. Why is a name relevant to anything? If you can add fields >> to a struct with a name [...] > > This corresponds to the following C constructs: > > struct S; // create struct with name but no fields > ... > struct S
2011 Jun 25
3
[LLVMdev] inefficiencies in ConstantUniqueMap ?
Hi Chris, > 3. Clang/dragonegg need to adapt to the new API (help appreciated!) what needs to be done exactly? Ciao, Duncan.
2011 Jun 30
0
[LLVMdev] inefficiencies in ConstantUniqueMap ?
On 27 June 2011 18:58, Chris Lattner <clattner at apple.com> wrote: > > On Jun 25, 2011, at 11:59 AM, Jay Foad wrote: > >> I've played with the Clang bits of this. The biggest problem I've >> found is that Clang uses LLVM's type resolution not just for >> forward-declared structs/classes/unions, which convert >> straightforwardly to the new
2011 Jun 30
5
[LLVMdev] inefficiencies in ConstantUniqueMap ?
Hi Jay, > As I understand it, PATypeHolder, OpaqueType and the Module's > TypeSymbolTable are gone. Instead, StructTypes can optionally be > named, and if they are then: > > - they use name equivalence instead of structural equivalence. > - you can create them without any fields, and then add the fields > later when the struct is complete. I find this distinction between
2011 Jun 27
2
[LLVMdev] inefficiencies in ConstantUniqueMap ?
On Jun 25, 2011, at 11:59 AM, Jay Foad wrote: > On 25 June 2011 13:00, Duncan Sands <baldrick at free.fr> wrote: >>> 3. Clang/dragonegg need to adapt to the new API (help appreciated!) >> >> what needs to be done exactly? > > Background info: http://www.nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt > > As I understand it, PATypeHolder, OpaqueType
2009 Jan 21
2
[LLVMdev] RFA: Constant String c"\000"
The Constants.cpp file returns a ConstantAggregateZero object when you pass it a c"\000" string. Here is the code: Constant *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())
2013 Oct 16
0
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > > In beginModule, we construct the CUs, but not all the DIEs that belong >>>> to the CU. >>>> In endFunction, we started to construct the scope DIEs. So in some >>>> sense, we are adding things to prior CUs. >>>> >>>> Looking at void
2005 May 03
0
[LLVMdev] VC++ build broken
On Mon, 2 May 2005, Jeff Cohen wrote: > Yes, that will work. I'll make the change. While you're at it, please remove this line, which is dead: if (V2->isNullValue()) return 0; Thanks, -Chris > Chris Lattner wrote: > >> On Mon, 2 May 2005, Jeff Cohen wrote: >> >>> The recently added code: >>> static Constant *Div(const ConstantClass *V1,
2020 Apr 30
2
Discrepancy between Debug and Release+Asserts versions of Clang/LLVM
Hello, I am editing the LowerTypeTests pass in LLVM, and part of my additions include the following 3 lines of code: // newTypeName is a std::string MDString* newMD = MDString::get(M.getContext(), newTypeName); ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD}; auto* node = MDTuple::get(M.getContext(), mdArray); Thus far, I have been developing on a version of Clang with
2013 Oct 16
0
[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
On Wed, Oct 16, 2013 at 11:10 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> In beginModule, we construct the CUs, but not all