[llvm-dev] What is the right lowering for misaligned memory access?

[Robin Kruppe via llvm-dev]

On 11 July 2018 at 18:52, Jon Chesterfield via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> What should a well behaved back end do with a load or store with alignment
> less than the natural alignment of the type?
>
> I believe C++ considers such access to be UB. I'm not sure what the IR
> semantics are.

Hi Jon,

IR semantics are: memory accesses are legal if the pointer is aligned
as annotated on the load/store/etc. instruction, the type's alignment
is irrelevant for definedness. The type's ABI alignment (defined by
the DataLayout string) is only used as a default if an instruction
doesn't have an alignment set -- but many frontends, including Clang,
always set it -- and natural alignment is completely irrelevant for IR
semantics AFAIK, it just usually agrees with ABI alignment.

For example, in the definition of both load and store instructions,
the language reference states: "Overestimating the alignment results
in undefined behavior. Underestimating the alignment may produce less
efficient code. An alignment of 1 is always safe."

> I think my options are:
> - Delete the operation / use undef
> - Lower as if it is naturally aligned
> - Lower via inefficient code that assumes align 1

By the IR semantics explained above, only the last option is allowed.
This is not just an idle curiosity, frontends other than Clang and
also (as David pointed out) some optimizations will sometimes emit
under-aligned accesses and reasonably expect them to work. Of course
that doesn't happen lightly, due to the potential performance issues,
but there are some good use cases for it, e.g. when operating on data
structures that omit padding to conserve space or when it's the only
unaligned access in a loop that could otherwise be vectorized to great
benefit.

For completeness, "emitting inefficient code" is your only option _if_
 your target really has no better option of implementing unaligned
accesses semantics. If your target processor can perform such
loads/stores (even if they're very slow) or if the generated code can
be assumed to execute in an environment where a trap handler emulates
unaligned accesses, you can emit an ordinary load or store instruction
without extra bells and whistles.


Cheers,

Robin


> Thanks,
>
> Jon
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>