[llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.

[James Y Knight via llvm-dev]

On Thu, Apr 15, 2021 at 12:58 PM Reid Kleckner <rnk at google.com> wrote:

> On Wed, Apr 14, 2021 at 11:58 AM James Y Knight via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> What I suspect you *actually* want here is an option to tell Clang not
>> to infer load/store alignments based on object types or alignment
>> attributes -- instead treating everything as being potentially aligned to 1
>> unless the allocation is seen (e.g. global/local variables). Clang would
>> still need to use the usual alignment computation for variable definitions
>> and structure layout, but not memory operations. If clang emits "load ...
>> align 1" instructions in LLVM IR, the right thing would then happen in the
>> X86 backend automatically.
>>
>
> This sounds like the -fmax-type-align flag:
> https://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
> Explicit alignment attributes are still honored, so some aligned vector
> instructions may be generated. However, the documentation describes
> essentially this exact use case.
>

Wow, thanks! Somehow I've missed that this flag has existed all this time.
ISTM that it would be reasonable to modify -fmax-type-align to override
even an explicit alignment attribute on the type (or typedef).

It looks like -fmax-type-align is barely used in the wild, except that
-fmax-type-align=16 is _default_ for Darwin platforms (since commit
bcd82afad64a22b15000de350d075b10f2de273a
<https://github.com/llvm/llvm-project/commit/bcd82afad64a22b15000de350d075b10f2de273a>).
It's unclear to me what purpose that default is really serving, however,
given that the only types with greater "native" alignment than 16 are
vector types, and typically used vector typedefs already have an alignment
specified, such as `typedef float __m256 __attribute__ ((__vector_size__
(32), __aligned__(32)));`. So the most-commonly-used vector types are
exempted from the effect of the flag, anyways...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210416/74c54f7e/attachment.html>