Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] creating a constant with the address of another constant"
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
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
Hi Evan,
Evan Cheng wrote:
> 1) How are you computing size of the method being
> jitted?
I add a new pass with addSimpleCodeEmitter, with the emitter being a
SizeEmitter. Since the target calls the emitter with functions such as
writeByte, writeWord, etc.... the SizeEmitter class implements these
function by incrementing a counter.
At the end of the pass, the code size of the
2008 Apr 04
3
[LLVMdev] Being able to know the jitted code-size before emitting
Evan Cheng wrote:
> On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote:
>
>
> That's a hack. :-)
It is if you think that code emitter should only be used for actually
writing somewhere the data. It is not if you find it another useful
utility ;-)
> Some targets already have ways to compute the exact
> size of a function. See ARM::GetFunctionSize()
2008 Apr 05
2
[LLVMdev] Being able to know the jitted code-size before emitting
Evan Cheng wrote:
>
> Let's see. ARM has it already. PPC has getNumBytesForInstruction so
> you only need to add one to compute function size. Also you only need
> to implement it for targets that support JIT right now, which leaves
> Alpha and X86. I'm guessing Alpha is using fixed encoding so it should
> be pretty easy. Or you can just punt it and let the target
2008 Mar 31
0
[LLVMdev] Being able to know the jitted code-size before emitting
Hi,
Two questions. 1) How are you computing size of the method being
jitted? 2) Why not simply add the functionality of allocating emission
buffer of specific size to MachineCodeEmitter instead?
Thanks,
Evan
On Mar 30, 2008, at 12:05 PM, Nicolas Geoffray wrote:
> Hi everyone,
>
> vmkit requires to know the size of a jitted method before emitting
> the method. This allows to
2008 Apr 01
0
[LLVMdev] Being able to know the jitted code-size before emitting
On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote:
> Hi Evan,
>
> Evan Cheng wrote:
>> 1) How are you computing size of the method being
>> jitted?
>
> I add a new pass with addSimpleCodeEmitter, with the emitter being a
> SizeEmitter. Since the target calls the emitter with functions such as
> writeByte, writeWord, etc.... the SizeEmitter class implements these
2008 Apr 05
0
[LLVMdev] Being able to know the jitted code-size before emitting
On Apr 4, 2008, at 11:16 PM, Nicolas Geoffray
<nicolas.geoffray at lip6.fr> wrote:
> Evan Cheng wrote:
>>
>> Let's see. ARM has it already. PPC has getNumBytesForInstruction so
>> you only need to add one to compute function size. Also you only need
>> to implement it for targets that support JIT right now, which leaves
>> Alpha and X86. I'm
2008 Apr 04
0
[LLVMdev] Being able to know the jitted code-size before emitting
On Apr 4, 2008, at 5:50 AM, Nicolas Geoffray wrote:
> Evan Cheng wrote:
>> On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote:
>>
>>
>> That's a hack. :-)
>
> It is if you think that code emitter should only be used for actually
> writing somewhere the data. It is not if you find it another useful
> utility ;-)
Except it's pretty slow at it. :-)
2008 Apr 07
2
[LLVMdev] Being able to know the jitted code-size before emitting
Hi Evan,
Evan Cheng wrote:
>
> I don't think the duplication is going to be top much of a problem. If
> it is, I'll bug you about refactoring. :)
>
>
I don't mean to show how lazy I can be, but I also need to know the size
of the exception table emitted in memory (JITDwarfEmitter.cpp).
Reviewing it a little, I can not see how things won't be duplicated.
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]
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
2016 Jan 15
2
Expanding a PseudoOp and accessing the DAG
On Thu, Jan 14, 2016 at 6:05 AM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> On 1/13/2016 4:47 PM, Phil Tomson wrote:
>
>>
>> First off, I got this idea from the LLVM Cookbook chapter 8: Writing an
>> LLVM Backend: Lowering to multiple instructions. (now I'm having my
>> doubts as to whether this is the right approach)
>>
>
>
2016 Jan 13
2
Expanding a PseudoOp and accessing the DAG
On Wed, Jan 13, 2016 at 2:08 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 1/13/2016 2:26 PM, Phil Tomson via llvm-dev wrote:
>
>> I've got this PseudoOp defined:
>>
>> def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>;
>> def XSTGRELADDR :
2009 Jun 11
0
[LLVMdev] patch for llc/ARM: added mechanism to move switch tables from .text -> .data; also cleanup and documentation
On Jun 8, 2009, at 2:42 PM, robert muth wrote:
> On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>
> wrote:
>>
>> On Jun 7, 2009, at 6:59 AM, robert muth wrote:
>>
>>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com>
>>> wrote:
>>>> +cl::opt<std::string>
2009 Apr 20
0
[LLVMdev] A few questions from a newbie
On 20/04/2009, at 07.35, Peter Bacon wrote:
> Hello, I am learning to write a new backend for LLVM and have a few
> simple questions.
Hi Peter,
I am a newbie too, but I have recently dealt with the same issues.
> 1) What are the differences between 'constant' and 'targetconstant',
> 'globaladdress' and 'targetglobaladdress'? It is not clear from
2013 Apr 12
1
[LLVMdev] Problem with Store of i8 in a global address
Hi,
I am creating a new backend for a custom microcontroller.
In order to create the backend I am modifying from Mips backend.
My architecture has a store instruction with direct address mode. It
accepts two arguments: source register and address (immediate). This
instruction is not available in Mips, but it is in Hexagon, so I copied
from Hexagon the following, adapting it to my registers:
-
2018 Sep 06
3
Did anything weird happen to the git monorepo?
Hi,
I got a forced update when pulling today. If I merge master to a local
branch, I get a bunch of add/add conflicts.
This same commit exists under several hashes:
https://github.com/llvm-project/llvm-project-20170507/commit/687841777ef505
https://github.com/llvm-project/llvm-project-20170507/commit/74725885552
Did someone push -f to the monorepo after doing branch surgery?
Maybe there was a
2009 Jun 08
2
[LLVMdev] patch for llc/ARM: added mechanism to move switch tables from .text -> .data; also cleanup and documentation
On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> On Jun 7, 2009, at 6:59 AM, robert muth wrote:
>
>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com>
>> wrote:
>>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section",
>>> +
2008 Sep 13
2
[LLVMdev] Alignment of constant loads
On Fri, September 12, 2008 11:33 am, Stefanus Du Toit wrote:
> Hi,
>
> We've noticed that constant loads, e.g. of v4f32 types, are not
> aligned to the preferred alignment but rather to the ABI alignment, at
> least on x86.
On x86 targets it's usually 16 for both preferred and ABI.
I guess you're using a target with a lower ABI alignment for
vectors?
> This seems to