[llvm-dev] Loop vectorizer doesn't try to align vectors on preferred vector alignment

[Mehdi AMINI via llvm-dev]

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>