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 4Yes, correct.> > > Has the format for the extension of the load/store bytecode been > determined?Nothing decided yet.> This would need to be applied to both normal and volatile load/store > instructions, and I see three options. > > > 1. Add the ability to encode optional arguments on any load/store and > volatile variants. This is general, but I can see why it could be bad > given how frequent load/stores tend to be. Perhaps this is why pseudo > ops were chosen for the volatile versions? > > > 2. Create pseudo opcodes for the permutations of volatility and > alignment. This will consume 4 more opcodes, but it would not bloat > the bytecode when natural alignment is used. > > > 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 or 3 is better.3 is best. opcodes are at a premium (six bits) and consuming 8 or more of them for load/store won't work (there isn't enough left). #2 could work but it penalizes the (hopefully more common) natural alignment case. So, I would just conver the Store+Volatile and Load+Volatile opcodes into Store+Attributes and Load+Attributes. Then the volatile and alignment attributes can be added for those (relatively uncommon) cases. Thanks for looking into this Christopher! Reid.> > > Thanks > -- > Christopher Lamb > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 or 3 is better. > > 3 is best. opcodes are at a premium (six bits) and consuming 8 or more > of them for load/store won't work (there isn't enough left). #2 could > work but it penalizes the (hopefully more common) natural alignment > case. So, I would just conver the Store+Volatile and Load+Volatile > opcodes into Store+Attributes and Load+Attributes. Then the > volatile and > alignment attributes can be added for those (relatively uncommon) > cases.Sounds good. 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. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070401/6f902e68/attachment.html>
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/