Benoit Meister via llvm-dev
2018-Apr-11 22:24 UTC
[llvm-dev] Loop vectorizer doesn't try to align vectors on preferred vector alignment
Hello, I'm playing around with vectorization in LLVM 6.0.0, and I noticed that when creating a vector load out of a scalar load, the alignment for the vector load is defined to be the one of the scalar load. For instance, 16-bit vectors get aligned on 2 bytes. This does not correspond to the preferred alignment for vectors that I specified in the data layout (which is bigger). Inspecting lib/Transforms/Vectorize/LoopVectorizer.cpp, there doesn't seem to be an intent of doing so. I looked at this method in particular: void InnerLoopVectorizer::vectorizeMemoryInstruction Is there a way (that I missed) to make this happen, or would it require a code change ? Or did I miss anything obvious ? Thanks in advance, - Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180411/a6fc5a6d/attachment.html>
Mehdi AMINI via llvm-dev
2018-Apr-11 22:38 UTC
[llvm-dev] Loop vectorizer doesn't try to align vectors on preferred vector alignment
Hi Benoit, Le mer. 11 avr. 2018 à 15:25, Benoit Meister via llvm-dev < llvm-dev at lists.llvm.org> a écrit :> Hello, > > I'm playing around with vectorization in LLVM 6.0.0, and I noticed that > when creating a vector load out of a scalar load, the alignment for the > vector load is defined to be the one of the scalar load. For instance, > 16-bit vectors get aligned on 2 bytes. This does not correspond to the > preferred alignment for vectors that I specified in the data layout (which > is bigger). > > Inspecting lib/Transforms/Vectorize/LoopVectorizer.cpp, there doesn't seem > to be an intent of doing so. > I looked at this method in particular: > > void InnerLoopVectorizer::vectorizeMemoryInstruction > > Is there a way (that I missed) to make this happen, or would it require a > code change ? Or did I miss anything obvious ? > >If the original pointer before vectorization is aligned on 2 bytes boundary, the loop vectorizer can't "promote" it to the new alignment without adding checks (or code versioning) right? Are you in a different case? Also, did you see this description about the alignment in the data layout in LangRef: "The function of the data layout string may not be what you expect. Notably, this is not a specification from the frontend of what alignment the code generator should use. Instead, if specified, the target data layout is required to match what the ultimate *code generator* expects. This string is used by the mid-level optimizers to improve code, and this only works if it matches what the ultimate code generator uses. There is no way to generate IR that does not embed this target-specific detail into the IR. If you don’t specify the string, the default specifications will be used to generate a Data Layout and the optimization phases will operate accordingly and introduce target specificity into the IR with respect to these default specifications." Cheers, -- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180411/fa68307f/attachment.html>
Benoit Meister via llvm-dev
2018-Apr-12 14:34 UTC
[llvm-dev] Loop vectorizer doesn't try to align vectors on preferred vector alignment
On Thu, Apr 12, 2018, 8:40 AM Benoit Meister <meister at reservoir.com> wrote:> Thank you, Ayal! And thanks for the quote, Mehdi. I believe it says that > it would be a normal thing for the Loop Vectorizer to conform to the > backend's preferred alignment constraints as given by the datalayout. > > On Thu, Apr 12, 2018, 3:24 AM Zaks, Ayal <ayal.zaks at intel.com> wrote: > >> Hi Benoit, >> >> >> >> > Is there a way (that I missed) to make this happen, or would it >> require a code change ? >> >> >> >> It’s the latter… there’s indeed room to make LV (and SLP) vectorizers >> optimize for larger more efficient alignment, using static analysis and/or >> dynamic peeling/versioning etc. >> >> Cf. LoadStoreVectorizer’s use of getOrEnforceKnownAlignment(). >> >> >> >> Ayal. >> >> >> >> >> >> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Mehdi >> AMINI via llvm-dev >> *Sent:* Thursday, April 12, 2018 01:39 >> *To:* meister at reservoir.com >> *Cc:* llvm-dev <llvm-dev at lists.llvm.org> >> *Subject:* Re: [llvm-dev] Loop vectorizer doesn't try to align vectors >> on preferred vector alignment >> >> >> >> Hi Benoit, >> >> >> >> Le mer. 11 avr. 2018 à 15:25, Benoit Meister via llvm-dev < >> llvm-dev at lists.llvm.org> a écrit : >> >> Hello, >> >> >> >> I'm playing around with vectorization in LLVM 6.0.0, and I noticed that >> when creating a vector load out of a scalar load, the alignment for the >> vector load is defined to be the one of the scalar load. For instance, >> 16-bit vectors get aligned on 2 bytes. This does not correspond to the >> preferred alignment for vectors that I specified in the data layout (which >> is bigger). >> >> >> >> Inspecting lib/Transforms/Vectorize/LoopVectorizer.cpp, there doesn't >> seem to be an intent of doing so. >> >> I looked at this method in particular: >> >> >> void InnerLoopVectorizer::vectorizeMemoryInstruction >> >> >> >> Is there a way (that I missed) to make this happen, or would it require a >> code change ? Or did I miss anything obvious ? >> >> >> >> >> >> If the original pointer before vectorization is aligned on 2 bytes >> boundary, the loop vectorizer can't "promote" it to the new alignment >> without adding checks (or code versioning) right? >> >> Are you in a different case? >> >> >> >> Also, did you see this description about the alignment in the data layout >> in LangRef: >> >> >> >> "The function of the data layout string may not be what you expect. >> Notably, this is not a specification from the frontend of what alignment >> the code generator should use. >> >> Instead, if specified, the target data layout is required to match what >> the ultimate *code generator* expects. This string is used by the >> mid-level optimizers to improve code, and this only works if it matches >> what the ultimate code generator uses. There is no way to generate IR that >> does not embed this target-specific detail into the IR. If you don’t >> specify the string, the default specifications will be used to generate a >> Data Layout and the optimization phases will operate accordingly and >> introduce target specificity into the IR with respect to these default >> specifications." >> >> Cheers, >> >> -- >> >> Mehdi >> >> >> >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180412/ae782600/attachment-0001.html>
Maybe Matching Threads
- Loop vectorizer doesn't try to align vectors on preferred vector alignment
- [LLVMdev] Limit loop vectorizer to SSE
- [Proposal][RFC] Epilog loop vectorization
- RFC: New intrinsics masked.expandload and masked.compressstore
- [LLVMdev] Limit loop vectorizer to SSE