similar to: [LLVMdev] PR400 - alignment for LD/ST

On Mar 29, 2007, at 12:24 PM, Christopher Lamb wrote: > Is anyone actively working on this currently? It's marked as > unassigned in BZ. In next few days I'll get to this. At the moment I'm enabling Packed Structure support in llvm-gcc (based on patches developed by other llvm developers) and adding support for packed bit fields. As part of this work, alignment for

Christopher, On Mar 29, 2007, at 12:49 PM, Devang Patel wrote: > > On Mar 29, 2007, at 12:24 PM, Christopher Lamb wrote: > >> Is anyone actively working on this currently? It's marked as >> unassigned in BZ. > > In next few days I'll get to this. At the moment I'm enabling Packed > Structure support in llvm-gcc (based on patches developed by other >

It would be really nice if llvm-as had some extra syntax to let other compilers specify the exact layout of a struct. Specifically, I'd like to specify what the byte offsets are for each field without having to insert phony fields. Would this extra functionality fit into your work at all? -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

On Mar 29, 2007, at 3:54 PM, Devang Patel wrote: > Christopher, > > On Mar 29, 2007, at 12:49 PM, Devang Patel wrote: > >> >> On Mar 29, 2007, at 12:24 PM, Christopher Lamb wrote: >> >>> Is anyone actively working on this currently? It's marked as >>> unassigned in BZ. >> >> In next few days I'll get to this. At the moment

On Mar 29, 2007, at 2:42 PM, Christopher Lamb wrote: > I'm not really sure exactly what's left to do to fully implement > what I need. I had assumed that this work would allow me to > determine if a LD/ST was based on an aligned pointer or not, but > this seems now like the tip of the iceberg. > > I'm hoping that I can declare aligned types and retain that

On Mar 30, 2007, at 11:10 AM, Devang Patel wrote: > > On Mar 29, 2007, at 2:42 PM, Christopher Lamb wrote: > >> I'm not really sure exactly what's left to do to fully implement >> what I need. I had assumed that this work would allow me to >> determine if a LD/ST was based on an aligned pointer or not, but >> this seems now like the tip of the

On Apr 2, 2007, at 5:01 PM, Devang Patel wrote: > > On Apr 2, 2007, at 2:12 PM, Chris Lattner wrote: >> >> Devang, do you have any thoughts on this or idea of how it would >> impact a >> vectorizor? > > When you say "load is multiple of 4 bytes away from a 8-byte aligned > data" > it is not clear whether it is 16-byte aligned or not. However,

On Mar 30, 2007, at 10:29 AM, Christopher Lamb wrote: >> 1) Update LLVM LD/ST instructions to maintain alignment information > > Is this referring to the language itself, i.e. the bytecode/ > assembly format and associated readers/writers? If so this is > probably the portion that it's most likely I could help with. > Yes. - Devang -------------- next part

On Mon, 2 Apr 2007, Christopher Lamb wrote: >> In this model, you represent each alignment value as a pair <align,offs>, >> where offs is always less than align. This allows you to say that "this >> load is 2 bytes away from a 16-byte aligned pointer" for example. > > Shouldn't it be, "this load is a multiple of 2-bytes away from a 16-byte >

On Apr 2, 2007, at 2:01 PM, Chris Lattner wrote: > On Mon, 2 Apr 2007, Christopher Lamb wrote: >> Here's a related question. It seems that there might be a benefit >> in knowing >> about two alignment values for a load/store. The alignment of the >> load/store >> itself, but potentially also the alignment of the base pointer >> used for the

On Mon, 2 Apr 2007, Christopher Lamb wrote: > Here's a related question. It seems that there might be a benefit in knowing > about two alignment values for a load/store. The alignment of the load/store > itself, but potentially also the alignment of the base pointer used for the > load/store. Having an alignment attribute on pointer types would solve both > these issues, but

On Mar 30, 2007, at 12:30 PM, Devang Patel wrote: > > On Mar 30, 2007, at 10:29 AM, Christopher Lamb wrote: > >>> 1) Update LLVM LD/ST instructions to maintain alignment information >> >> Is this referring to the language itself, i.e. the bytecode/ >> assembly format and associated readers/writers? If so this is >> probably the portion that it's

On Apr 2, 2007, at 4:07 PM, Christopher Lamb wrote: > > On Apr 2, 2007, at 5:01 PM, Devang Patel wrote: > >> >> However, that means, for loops this becomes "load is N bytes away >> from a 8-byte aligned data" where N is dependent on IV. I said, this but I am not sure it is OK to say %tmp = load i32* %tmp1, align N > > So in the loop case analysis of

On Apr 2, 2007, at 2:12 PM, Chris Lattner wrote: > > Devang, do you have any thoughts on this or idea of how it would > impact a > vectorizor? When you say "load is multiple of 4 bytes away from a 8-byte aligned data" it is not clear whether it is 16-byte aligned or not. However, "load is 4 bytes away from a 8-byte aligned data" is clear - it is aligned at

On Apr 1, 2007, at 3:11 AM, Chris Lattner wrote: > On Sun, 1 Apr 2007, Christopher Lamb wrote: >> Also I wanted to clear something up about the meaning of the >> alignment >> attribute. My thinking is that this indicates over/under alignment >> with >> respect to natural alignment for the type. This is to say in the >> Load/Store >> instruction

Hi Christopher, On Sat, 2007-03-31 at 15:43 -0500, Christopher Lamb wrote: > > > For the assembly format I assume that it would be a simple optional > comma delimited alignment parameter at the end of the instruction, > such as: > > > %tmp5 = load i32* %tmp4, align 4 > store i32 %val, i32* %tmp3, align 4 Yes, correct. > > > Has the format for the

On Apr 1, 2007, at 3:11 AM, Chris Lattner wrote: > On Sun, 1 Apr 2007, Christopher Lamb wrote: >> Also I wanted to clear something up about the meaning of the >> alignment >> attribute. My thinking is that this indicates over/under alignment >> with >> respect to natural alignment for the type. This is to say in the >> Load/Store >> instruction

On Sun, 1 Apr 2007, Christopher Lamb wrote: > Also I wanted to clear something up about the meaning of the alignment > attribute. My thinking is that this indicates over/under alignment with > respect to natural alignment for the type. This is to say in the Load/Store > instruction classes the default alignment value will be zero, meaning natural > alignment for the given type.

On Mar 31, 2007, at 4:16 PM, Reid Spencer wrote: >> 3. Create pseudo ops for 'attributed' load/store instructions. These >> instructions contain a set of optional attributes encoded in some >> way. >> The current volatile load/store instructions could be subsumed by >> these instructions. >> >> I'm leaning away from 1, but unsure whether 2

Ok. This got a little over my head, but what I take away is: 1. I'll submit a patch for just the alias parameter on loads and stores. The alias parameter indicates the final alignment of the load or store (nothing to do with base+imm or base+offset addressing). 2. The more sophisticated alignment information for vectorization of loads/stores will likely have to be implemented as an