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