llvm dev - Jul 2018 - What is the right lowering for misaligned memory access?

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.

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

Thanks,

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180711/26bb4c9f/attachment.html>

I would say #4: Lower via inefficient code that assumes the alignment
specified by the load or store.  If no alignment is specified, assume
align 1.

As far as UB, it's not just a language issue.  A vector load could be
unaligned even if the original scalar access was aligned.  Whether such
vectorization is legal is target-dependent.  In the worst case, a
backend for a target requiring strict vector alignment would have to
scalarize the load.

The point of all that is that unaligned accesses are not all that
uncommon and it seems wrong to eliminate them or lower them as if they
were aligned.  The target legalizer should convert problematic unaligned
loads to legal code, which is essentially "lower via inefficient
code."

                          -David


Jon Chesterfield via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 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.
>
> 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
>
> Thanks,
>
> Jon
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Wed, Jul 11, 2018 at 05:52:24PM +0100, Jon Chesterfield via llvm-dev
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.
> 
> 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
Unless the operation explicitly specifies something else (i.e. via
memcpy), the second option is correct. Don't go out of your way to break
unaligned access, esp. if the target CPU can deal with it. But don't go
out of your way to make it work either.

Joerg

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
>

Thank you all. That is an exceptionally clear response.

For completeness, "emitting inefficient code" is your only option
_if_
>  your target really has no better option of implementing unaligned
> accesses semantics.
>
There the usual tradeoffs in the implementation. Simplicity / correctness /
performance / memory / dev time. Deleting the instructions fails on
correctness and per byte is too slow. I'll write something reasonable for
the ISA.

Cheers

Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180711/54b0e740/attachment.html>