On 6/18/07, Chris Lattner <sabre at nondot.org> wrote:> On Mon, 18 Jun 2007, Sandro Magi wrote: > > Ok, so if I needed very precise control over the allocation of memory, > > then I should avoid using integers with bit widths larger than 64 bits > > (or perhaps 128)? Is there a hard rule for an integer being stack > > allocated, ie. one that doesn't depend on the current implementation > > details? > > In the generated code, or in the compiler itself? Reid is talking about > how the compiler itself is implemented, I was describing how the generated > code works.Generated code. So the memory used for the integer at program runtime is inlined into the allocation point then? So if I define a local variable of type 'i1024', it will allocate a block of 1024 bits on the stack, if I define a struct with an i1024, it will be in the struct itself, etc. Is there anyone working on complete support for this in the code generators? Sandro
On Mon, 18 Jun 2007, Sandro Magi wrote:> Generated code. So the memory used for the integer at program runtime > is inlined into the allocation point then? So if I define a local > variable of type 'i1024', it will allocate a block of 1024 bits on the > stack, if I define a struct with an i1024, it will be in the struct > itself, etc.Yes, exactly.> Is there anyone working on complete support for this in the code generators?Nope, not that I know of. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Lattner wrote:>On Mon, 18 Jun 2007, Sandro Magi wrote: > > >>Generated code. So the memory used for the integer at program runtime >>is inlined into the allocation point then? So if I define a local >>variable of type 'i1024', it will allocate a block of 1024 bits on the >>stack, if I define a struct with an i1024, it will be in the struct >>itself, etc. >> >> > >Yes, exactly. > >Unless something has changed recently, both of these i1024 examples will generate an assertion in the SelectionDAG somewhere. You basically can't go past 128 in code gen right now, AFAIK.> > >>Is there anyone working on complete support for this in the code generators? >> >> > >Nope, not that I know of. > >-Chris > > >