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 -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070330/7b3bf153/attachment.html>
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 most likely I could help with. >> > > Yes.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 Has the format for the extension of the load/store bytecode been determined? 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. Thanks -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070331/67fc5c79/attachment.html>
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