Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] jump table ?"
2006 Jun 28
0
[LLVMdev] jump table ?
On Wed, 28 Jun 2006, Simon Burton wrote:
> Is it possible to take the address
> of a basic block ?
Nope.
> I'd like to put a whole bunch of these
> addresses into an array, and then select
> one to branch to. Eg. like a switch statement.
> (i'm thinking also of GCC's computed goto's)
llvm-gcc supports gcc's computed goto's. You can see what code it
2006 Jun 29
4
[LLVMdev] jump table ?
On Wed, 28 Jun 2006 11:53:56 -0500 (CDT)
Chris Lattner <sabre at nondot.org> wrote:
> On Wed, 28 Jun 2006, Simon Burton wrote:
> > Is it possible to take the address
> > of a basic block ?
>
> Nope.
>
> > I'd like to put a whole bunch of these
> > addresses into an array, and then select
> > one to branch to. Eg. like a switch statement.
>
2006 Jun 29
0
[LLVMdev] jump table ?
On Thu, 29 Jun 2006, Simon Burton wrote:
>> LLVM does support switch table emission, but only in certain modes. I
>> think it's only supported in non-pic codegen mode. Patches to improve
>> this would be welcome :)
>
> I am not sure what "non-pic codegen mode" is.
> PIC is relocatable code ? ie. object files ?
> So if i'm using the JIT then it will
2010 Feb 23
2
[LLVMdev] Disabling emission of jump table info
I've recently changed the XCore target to implement BR_JT as a jump to a
series jumps. The jump table entries are expand inline in the function
so there is no longer a need to emit jump tables at the end of the
function. However the emission of jump tables at the end of a function
is done inside the AsmPrinter base class and there seems to be no way of
disabling this.
This also seems to
2010 Mar 01
0
[LLVMdev] Disabling emission of jump table info
On 23/02/10 14:58, Richard Osborne wrote:
> I've recently changed the XCore target to implement BR_JT as a jump to a
> series jumps. The jump table entries are expand inline in the function
> so there is no longer a need to emit jump tables at the end of the
> function. However the emission of jump tables at the end of a function
> is done inside the AsmPrinter base class and
2010 Mar 01
2
[LLVMdev] Disabling emission of jump table info
On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote:
> On 23/02/10 14:58, Richard Osborne wrote:
>> I've recently changed the XCore target to implement BR_JT as a jump to a
>> series jumps. The jump table entries are expand inline in the function
>> so there is no longer a need to emit jump tables at the end of the
>> function. However the emission of jump tables at
2010 Mar 02
0
[LLVMdev] Disabling emission of jump table info
On 01/03/10 21:14, Chris Lattner wrote:
> On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote:
>
>> On 23/02/10 14:58, Richard Osborne wrote:
>>
>>> I've recently changed the XCore target to implement BR_JT as a jump to a
>>> series jumps. The jump table entries are expand inline in the function
>>> so there is no longer a need to emit jump
2010 Mar 02
2
[LLVMdev] Disabling emission of jump table info
On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote:
> On 01/03/10 21:14, Chris Lattner wrote:
>> On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote:
>>
>>> On 23/02/10 14:58, Richard Osborne wrote:
>>>
>>>> I've recently changed the XCore target to implement BR_JT as a jump to a
>>>> series jumps. The jump table entries are
2010 Mar 09
0
[LLVMdev] Disabling emission of jump table info
On 02/03/10 00:11, Jim Grosbach wrote:
> On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote:
>
>> On 01/03/10 21:14, Chris Lattner wrote:
>>
>>> On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote:
>>>
>>>> On 23/02/10 14:58, Richard Osborne wrote:
>>>>
>>>>
>>>>> I've recently
2010 Mar 10
2
[LLVMdev] Disabling emission of jump table info
Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard!
-Chris
On Mar 9, 2010, at 6:06 AM, Richard Osborne wrote:
> On 02/03/10 00:11, Jim Grosbach wrote:
>> On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote:
>>
>>> On 01/03/10 21:14, Chris Lattner
2006 Apr 13
4
[LLVMdev] standalone llvm
Is it possible to get llvm to generate native machine code
without using gcc and friends ? Do I use lli ?
I'd like to directly create executable code that i can
stick in memory somewhere and jump into (call).
(I'm looking to use llvm in a BSD licensed project).
Simon.
--
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com
2006 May 05
2
[LLVMdev] ExecutionEngine blew the stack ?
On Fri, 5 May 2006, Simon Burton wrote:
> This leads me to my next question: as I make more and more functions
> with the EE, it slows down. I am re-using the Module, ExistingModuleProvider,
> and ExecutionEngine, and pumping the parser like so:
> M = ParseAssemblyString(AsmString, M);
> ISTM that there should be a way of creating multiple modules/EEs but I ran
> into trouble
2010 Mar 11
0
[LLVMdev] Disabling emission of jump table info
Thanks for reviewing this. Committed in r98255 and r98256. The bug
against the ARM backend is 6581:
http://llvm.org/bugs/show_bug.cgi?id=6581
On 10/03/10 21:45, Chris Lattner wrote:
> Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard!
>
> -Chris
>
> On Mar
2024 Dec 04
1
Linux desktop setup with authentication against Samba AD DC
On Wed, 4 Dec 2024 14:25:15 +0100
Peter Milesson via samba <samba at lists.samba.org> wrote:
> Hi Rowland,
>
> Essentially, my setup is mandatory in the context of what features
> are available to the users. Otherwise it's a vanilla Debian. The
> basic functionality is identical to a NFS setup with the users home
> directories stored on a server. When the user first
2006 Apr 15
2
[LLVMdev] Re: how to code a loop in llvm assembly
Simon Burton <simon at arrowtheory.com> writes:
> Hi,
>
> I've read over the "LLVM Language Reference Manual"
> a few times, and writing some ll code, but i'm stuck at
> a very basic point. How to decrement a counter variable ?
>
> int %count(int %n) {
> EntryBlock:
> %cond = seteq int %n, 0
> br bool %cond, label %Exit, label %Next
>
2006 Jun 21
3
[LLVMdev] size of generated machine code ?
On Tue, 20 Jun 2006, Chris Lattner wrote:
> On Wed, 21 Jun 2006, Simon Burton wrote:
>> This from the output:
>>
>> 24620 x86-emitter - Number of machine instructions emitted
>>
>> (i had to write a dummy main function to get this to work)
>>
>> Is this really the number of bytes of machine code ?
> Yes.
To be specific, this is the
2006 Apr 19
2
[LLVMdev] floating point exception and SSE2 instructions
On Tue, 18 Apr 2006 23:27:39 -0700
Evan Cheng <evan.cheng at apple.com> wrote:
> Hi Simon,
>
> The x86 backend does generate scalar SSE2 instructions. For your
> example, it should emit something like:
Oh, how did you get this ?
[...]
>
> There is nothing here that should cause an exception. Are you using a
> release or cvs?
CVS.
>From what I remember,
2006 Apr 19
2
[LLVMdev] floating point exception and SSE2 instructions
Hi,
I'm building a little JIT that creates functions to do array manipulations,
eg. sum all the elements of a double* array. I'm writing this in python, generating
llvm assembly intructions and piping that through a call to ParseAssemblyString,
ExecutionEngine, etc.
It's working OK on integer values, but i'm getting nasty floating point exceptions
when i try this on double*
2006 Jun 21
0
[LLVMdev] size of generated machine code ?
On Tue, 20 Jun 2006 22:38:24 -0500 (CDT)
Chris Lattner <sabre at nondot.org> wrote:
>
> >> Is this really the number of bytes of machine code ?
> > Yes.
>
> To be specific, this is the number of bytes of machine code JIT'd. Thus,
> this only includes the stuff reachable from main, for example. To see
> specifically what functions it is compiling and
2006 May 05
0
[LLVMdev] ExecutionEngine blew the stack ?
On Fri, 5 May 2006 01:19:08 -0500 (CDT)
Chris Lattner <sabre at nondot.org> wrote:
>
> On Fri, 5 May 2006, Simon Burton wrote:
> > This leads me to my next question: as I make more and more functions
> > with the EE, it slows down. I am re-using the Module, ExistingModuleProvider,
> > and ExecutionEngine, and pumping the parser like so:
> > M =