similar to: [LLVMdev] jump table ?

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 =