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. If the alignment value is nonzero then the > alignment value should be used over the natural or preferred alignment.Yes, exactly. To put this another way: if the specified alignment is less than the natural alignment for the type, then the codegen needs to be careful (e.g. use special unaligned loads). If it is more aligned, then this is a guarantee to clients about the load, who can choose to use it or not. If the specified alignment matches the natural alignment, then it can be dropped (set to zero). -Chris -- http://nondot.org/sabre/ http://llvm.org/
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 classes the default alignment value will be zero, >> meaning natural >> alignment for the given type. If the alignment value is nonzero >> then the >> alignment value should be used over the natural or preferred >> alignment. > > Yes, exactly. To put this another way: if the specified alignment > is less > than the natural alignment for the type, then the codegen needs to be > careful (e.g. use special unaligned loads). If it is more aligned, > then > this is a guarantee to clients about the load, who can choose to > use it or > not. If the specified alignment matches the natural alignment, > then it > can be dropped (set to zero).I have changes in places to implement the bytecode/assembly/ instruction changes and propagate them through to SDNode creation in the back end. Woot. When a load or store instruction of alignment 0 (natural) is visited in SelectionDAGLowering, should it create an SDNode of alignment 0 or should it use the TargetData to set the SDNode's alignment to the preferred alignment for the load/store's type for that particular target? -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070402/5af70097/attachment.html>
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 classes the default alignment value will be zero, >> meaning natural >> alignment for the given type. If the alignment value is nonzero >> then the >> alignment value should be used over the natural or preferred >> alignment. > > Yes, exactly. To put this another way: if the specified alignment > is less > than the natural alignment for the type, then the codegen needs to be > careful (e.g. use special unaligned loads). If it is more aligned, > then > this is a guarantee to clients about the load, who can choose to > use it or > not. If the specified alignment matches the natural alignment, > then it > can be dropped (set to zero). > > -ChrisHere'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? -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070402/b59e8c4e/attachment.html>
On Mon, 2 Apr 2007, Christopher Lamb wrote:> > I have changes in places to implement the bytecode/assembly/instruction > changes and propagate them through to SDNode creation in the back end. Woot.Great!> When a load or store instruction of alignment 0 (natural) is visited in > SelectionDAGLowering, should it create an SDNode of alignment 0 or should it > use the TargetData to set the SDNode's alignment to the preferred alignment > for the load/store's type for that particular target?I think it should use the target's abi alignment (not preferred alignment). This way, the codegen doesn't have to deal with alignment zero. Congrats! -Chris -- http://nondot.org/sabre/ http://llvm.org/
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/