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 >> load/store. Having an alignment attribute on pointer types would >> solve both >> these issues, but having a single alignment attribute on loads/stores >> doesn't. This would lead me to propose having an alignment >> attribute for >> getelementptr. Thoughts? > > I may be misunderstanding, if so, please correct me. However, I think > you're trying to bring addressing modes into this. Many targets > support > "reg+immediate" addressing modes... I assume you're trying to get an > alignment value for the 'reg' part, without the "immed" part?You are correct.> This approach would have a couple of problems. Instead, if you > wanted a > more general alignment model, I'd suggest going for representing > alignments as "offset from alignment". > > 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 aligned pointer", isn't that more general? The case I'm dealing with directly pertains to indexing arrays that are themselves aligned. This information allows loads/stores (say in an unrolled loop) to be coalesced as they can be determined to reference to the same memory. This would mean that the alignment of the load itself will be align if no offset is provided and min(align, offs) if an offset alignment is provided. Do you think it will be difficult for the front-end to provide these two alignments? Also, I've noticed that a some transformations on Loads/Stores don't preserve either volatility or alignment information. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070402/b2186b39/attachment.html>
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 having a single alignment attribute on loads/stores > doesn't. This would lead me to propose having an alignment attribute for > getelementptr. Thoughts?I may be misunderstanding, if so, please correct me. However, I think you're trying to bring addressing modes into this. Many targets support "reg+immediate" addressing modes... I assume you're trying to get an alignment value for the 'reg' part, without the "immed" part? This approach would have a couple of problems. Instead, if you wanted a more general alignment model, I'd suggest going for representing alignments as "offset from alignment". 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. -Chris -- http://nondot.org/sabre/ http://llvm.org/
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 > aligned pointer", isn't that more general?It is both more general and less precise :)> The case I'm dealing with directly pertains to indexing arrays that are > themselves aligned. This information allows loads/stores (say in an unrolled > loop) to be coalesced as they can be determined to reference to the same > memory.Ok.> This would mean that the alignment of the load itself will be align if no > offset is provided and min(align, offs) if an offset alignment is provided. > Do you think it will be difficult for the front-end to provide these two > alignments?The front-end won't be able to give you information about a loop of code that traverses an array, but subsequent optimization/analysis passes can. I think that either form of information would be easy to get, but I don't know what the tradeoffs are (loss of generality or loss of precision). Devang, do you have any thoughts on this or idea of how it would impact a vectorizor?> Also, I've noticed that a some transformations on Loads/Stores don't preserve > either volatility or alignment information.I'm not suprised about the alignment piece (it hasn't been filled in yet) but not preserving volatility is definitely a bug. -Chris -- http://nondot.org/sabre/ http://llvm.org/