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, "load > is 4 bytes > away from a 8-byte aligned data" is clear - it is aligned at 12-byte > and not > 16-byte. > > However, that means, for loops this becomes "load is N bytes away > from a 8-byte aligned data" where N is dependent on IV.So in the loop case analysis of the IV is necessary to determine the actual alignment? Would the form for the loops require that the offset be tracked as a multiple of the IV stride? Would the IV stride analysis normally be performed in the front end (and thus end up in the BC)? If this is the the case then I'd take Chris's suggestion of the <align, offs> pair, as it is clear in the static offset case and the actual alignment could be deduced, along with an <align, stride> pair for the IV case. This the previous meaning of simply <align> would be equivalent to <align, stride> where align == stride. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070402/5266d5e1/attachment.html>
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 the IV is necessary to determine > the actual alignment?only, if array index is based on IV> Would the form for the loops require that the offset be tracked as > a multiple of the IV stride?How to represent A[ I + 4], where I is IV ?> Would the IV stride analysis normally be performed in the front end > (and thus end up in the BC)?unlikely. Induction variable analysis pass is more suitable to provide this info. - Devang> If this is the the case then I'd take Chris's suggestion of the > <align, offs> pair, as it is clear in the static offset case and > the actual alignment could be deduced, along with an <align, > stride> pair for the IV case. This the previous meaning of simply > <align> would be equivalent to <align, stride> where align == stride.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070402/812c1942/attachment.html>
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 analysis pass and wouldn't need to be represented in the BC or assembly. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070403/da6e5b8d/attachment.html>