Displaying 20 results from an estimated 28 matches for "getconstantpool".
2008 Sep 13
2
[LLVMdev] Alignment of constant loads
...ctor types
> -- I think this may be a relic since getPreferredTypeAlignmentShift
> should not return zero for vector types -- correct me if I'm wrong!)
I'm not sure about that FIXME offhand, but overall it looks
like the work this code is doing would be better placed in
SelectionDAG::getConstantPool.
> Do you have a suggestion as to how we can make it so that loads for
> constants are aligned to the preferred alignment, rather than the ABI
> alignment? We're not sure where this should be "fixed".
It looks like the best way to do this is to visit the handful of
places i...
2008 Sep 15
0
[LLVMdev] Alignment of constant loads
...It looks like the best way to do this is to visit the handful of
> places in legalize that create loads from constant pools and
> add alignment parameters to the getLoad/getExtLoad calls.
>
> If you move the handling of Alignment==0 out of ScheduleDAGEmit.cpp
> and into SelectionDAG::getConstantPool, you can then have legalize
> read the alignment from the node, instead of making its own
> decision:
> cast<ConstantPoolSDNode>(CPIdx)->getAlignment()
>
>
I followed your suggestion but I've come across a bit of a snag. If you
get the alignment in LegalizeDAG usi...
2006 Aug 14
2
[LLVMdev] bug in CSEMap?
I am having some problems with the generated code having wrong
constants in the constant pull. Adding a dump of "C" and "E" in
SelectionDAG::getConstantPool I get
C:
----------------------------------------------------------
%str = internal constant [12 x sbyte] c"Hello World\00" ; <[12
x sbyte]*> [#uses=1]
-----------------------------------------------------------
E:
----------------------------------------------------------...
2006 Aug 14
0
[LLVMdev] Re: bug in CSEMap?
I think that the problem is in SelectionDAG::getConstantPool itself.
Only Alignment and Offset are used in the ID. This causes false
aliases.
X86TargetLowering::LowerFABS should also be affected. All of its calls
to getConstantPool have the same alignment and offset.
Best Regards,
Rafael
2008 Mar 30
3
[LLVMdev] Being able to know the jitted code-size before emitting
Hi everyone,
vmkit requires to know the size of a jitted method before emitting the
method. This allows to allocate the correct size for the method. The
attached patch creates this functionality when the flag SizedMemoryCode
is on.
In order to implement this functionality, i had to virtualize some
MachineCodeEmitter functions.
Is it OK to commit the patch?
Thanks,
Nicolas
--------------
2008 Apr 01
2
[LLVMdev] Being able to know the jitted code-size before emitting
...+ virtual void startFunction(MachineFunction &F) {
>> + CurBufferPtr = 0;
>> + Fn = &F;
>> +
>> + // Ensure the constant pool/jump table info is at least 4-byte
>> aligned.
>> + emitAlignment(16);
>> +
>> + initConstantPool(F.getConstantPool());
>> + initJumpTableInfo(F.getJumpTableInfo());
>> +
>> + ConstantPoolBase = (void*)(((uintptr_t) ConstantPoolBase) +
>> CurBufferPtr);
>> + JumpTableBase = (void*)(((uintptr_t) JumpTableBase) +
>> CurBufferPtr);
>> + }
>> +
>&...
2008 Mar 31
0
[LLVMdev] Being able to know the jitted code-size before emitting
...Info *MJTI);
> +
> +
> + virtual void startFunction(MachineFunction &F) {
> + CurBufferPtr = 0;
> + Fn = &F;
> +
> + // Ensure the constant pool/jump table info is at least 4-byte
> aligned.
> + emitAlignment(16);
> +
> + initConstantPool(F.getConstantPool());
> + initJumpTableInfo(F.getJumpTableInfo());
> +
> + ConstantPoolBase = (void*)(((uintptr_t) ConstantPoolBase) +
> CurBufferPtr);
> + JumpTableBase = (void*)(((uintptr_t) JumpTableBase) +
> CurBufferPtr);
> + }
> +
> + virtual bool finishFunction(M...
2008 Apr 01
0
[LLVMdev] Being able to know the jitted code-size before emitting
...MachineFunction &F) {
>>> + CurBufferPtr = 0;
>>> + Fn = &F;
>>> +
>>> + // Ensure the constant pool/jump table info is at least 4-byte
>>> aligned.
>>> + emitAlignment(16);
>>> +
>>> + initConstantPool(F.getConstantPool());
>>> + initJumpTableInfo(F.getJumpTableInfo());
>>> +
>>> + ConstantPoolBase = (void*)(((uintptr_t) ConstantPoolBase) +
>>> CurBufferPtr);
>>> + JumpTableBase = (void*)(((uintptr_t) JumpTableBase) +
>>> CurBufferPtr);
>>&g...
2008 Apr 04
3
[LLVMdev] Being able to know the jitted code-size before emitting
...t;>> + CurBufferPtr = 0;
>>>> + Fn = &F;
>>>> +
>>>> + // Ensure the constant pool/jump table info is at least 4-byte
>>>> aligned.
>>>> + emitAlignment(16);
>>>> +
>>>> + initConstantPool(F.getConstantPool());
>>>> + initJumpTableInfo(F.getJumpTableInfo());
>>>> +
>>>> + ConstantPoolBase = (void*)(((uintptr_t) ConstantPoolBase) +
>>>> CurBufferPtr);
>>>> + JumpTableBase = (void*)(((uintptr_t) JumpTableBase) +
>>>> C...
2008 Apr 05
2
[LLVMdev] Being able to know the jitted code-size before emitting
...t;>>>> +
>>>>>> + // Ensure the constant pool/jump table info is at least 4-
>>>>>> byte
>>>>>> aligned.
>>>>>> + emitAlignment(16);
>>>>>> +
>>>>>> + initConstantPool(F.getConstantPool());
>>>>>> + initJumpTableInfo(F.getJumpTableInfo());
>>>>>> +
>>>>>> + ConstantPoolBase = (void*)(((uintptr_t) ConstantPoolBase) +
>>>>>> CurBufferPtr);
>>>>>> + JumpTableBase = (void*)(((uintpt...
2008 Apr 05
0
[LLVMdev] Being able to know the jitted code-size before emitting
...t;>>>>>> + // Ensure the constant pool/jump table info is at least 4-
>>>>>>> byte
>>>>>>> aligned.
>>>>>>> + emitAlignment(16);
>>>>>>> +
>>>>>>> + initConstantPool(F.getConstantPool());
>>>>>>> + initJumpTableInfo(F.getJumpTableInfo());
>>>>>>> +
>>>>>>> + ConstantPoolBase = (void*)(((uintptr_t)
>>>>>>> ConstantPoolBase) +
>>>>>>> CurBufferPtr);
>>>>>...
2008 Apr 04
0
[LLVMdev] Being able to know the jitted code-size before emitting
...gt; + Fn = &F;
>>>>> +
>>>>> + // Ensure the constant pool/jump table info is at least 4-
>>>>> byte
>>>>> aligned.
>>>>> + emitAlignment(16);
>>>>> +
>>>>> + initConstantPool(F.getConstantPool());
>>>>> + initJumpTableInfo(F.getJumpTableInfo());
>>>>> +
>>>>> + ConstantPoolBase = (void*)(((uintptr_t) ConstantPoolBase) +
>>>>> CurBufferPtr);
>>>>> + JumpTableBase = (void*)(((uintptr_t) JumpTableBase)...
2008 Apr 07
2
[LLVMdev] Being able to know the jitted code-size before emitting
...t;> + // Ensure the constant pool/jump table info is at least 4-
>>>>>>>> byte
>>>>>>>> aligned.
>>>>>>>> + emitAlignment(16);
>>>>>>>> +
>>>>>>>> + initConstantPool(F.getConstantPool());
>>>>>>>> + initJumpTableInfo(F.getJumpTableInfo());
>>>>>>>> +
>>>>>>>> + ConstantPoolBase = (void*)(((uintptr_t)
>>>>>>>> ConstantPoolBase) +
>>>>>>>> CurBufferPtr);...
2008 Apr 07
0
[LLVMdev] Being able to know the jitted code-size before emitting
...at least
>>>>>>>>> 4-
>>>>>>>>> byte
>>>>>>>>> aligned.
>>>>>>>>> + emitAlignment(16);
>>>>>>>>> +
>>>>>>>>> + initConstantPool(F.getConstantPool());
>>>>>>>>> + initJumpTableInfo(F.getJumpTableInfo());
>>>>>>>>> +
>>>>>>>>> + ConstantPoolBase = (void*)(((uintptr_t)
>>>>>>>>> ConstantPoolBase) +
>>>>>>>>&...
2006 Aug 14
1
[LLVMdev] Re: bug in CSEMap?
On Mon, 14 Aug 2006, [UTF-8] Rafael Esp?ndola wrote:
> I think that the problem is in SelectionDAG::getConstantPool itself.
> Only Alignment and Offset are used in the ID. This causes false
> aliases.
Doh. Sorry about that, I just checked in a fix. Please verify that this
corrects the problem.
> X86TargetLowering::LowerFABS should also be affected. All of its calls
> to getConstantPool have the...
2009 Nov 10
4
[LLVMdev] Altivec vs the type legalizer
...pes
first promotes the element types to i32, then builds a constant pool
entry of type v16i32. This is wrong. I can fix it by truncating the
elements back to i8 in ExpandBUILD_VECTOR. Does this seem like the
right approach? I ask because we'll be relying on ConstantVector::get
and getConstantPool to work even with elements of a type that's
illegal for the target; currently, they do. (And I see no other way
to fix it except to break the vector into scalars, which produces
horrendous code.)
typedef vector unsigned char vuint8_t;
vuint8_t baz;
void foo(vuint8_t x) {
vuint8_t...
2011 May 07
0
[LLVMdev] Question about linking llvm-mc when porting a new backend
...Gen.a(EBCRegisterInfo.cpp.o)
"llvm::TargetMachine::getAsmVerbosityDefault()", referenced from:
getVerboseAsm() in libLLVMCodeGen.a(LLVMTargetMachine.cpp.o)
"llvm::TargetData::getPrefTypeAlignment(llvm::Type const*) const",
referenced from:
llvm::SelectionDAG::getConstantPool(llvm::MachineConstantPoolValue*,
llvm::EVT, unsigned int, int, bool, unsigned char)in
libLLVMSelectionDAG.a(SelectionDAG.cpp.o)
llvm::SelectionDAG::getConstantPool(llvm::Constant const*, llvm::EVT,
unsigned int, int, bool, unsigned char)in
libLLVMSelectionDAG.a(SelectionDAG.cpp.o)
llvm:...
2006 Jul 31
1
[LLVMdev] creating a constant with the address of another constant
In ARM, the conventional way of setting a register to a 32 bit
constant is to use a load:
---------------------------------
str:
.asciz "Hello World"
.text
main:
...
ldr r0, .L3
....
.L3:
.word str
-----------------------------------
To implement this, LowerGlobalAddress must add an element to the
constant pool (.L3 in the example). How can I implement this?
2006 Aug 17
1
[LLVMdev] allocation_order_begin takes non-const reference for MachineFunction
On Thu, 17 Aug 2006, Anton Vayvod wrote:
> Thanks, Ralph, this line worked well :)
> Here it is, my first patch to LLVM :)
> I've changed all allocation_order_begin() and allocation_order_end() methods
> to take const MachineFunction &MF as a parameter. I also added const version
> of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP()
>
2006 Oct 19
1
[LLVMdev] jump table x constant pool
I had some problems adding the address of a jump table to the constant
pool. The problem is that the address of a jump table is not a
GlobalValue.Currently I decided to expand BRIND so that I can work on
simpler problems :-)
A small brain dump on the issue:
GlobalValues are currently used to represent functions and global
variables. Maybe we could also use then for anything that will have a
label