[llvm-dev] Unaligned atomic load/store

Dr. ÉRDI Gergő via llvm-dev llvm-dev at lists.llvm.org
Sat Aug 26 07:50:47 PDT 2017


So does that mean that this assertion is simply being over-defensive in
anticipation of target-specific code further downstream failing on
non-aligned atomic operations? It seems like a much better place for an
assertion like this would be near the target-specific code (if any) that
needs this precondition.

Can you recommend a way forward? Should I add some new method that tells
the non-target-specific code the alignment requirements of the current
target?

On Aug 26, 2017 20:54, "Joerg Sonnenberger via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:

On Sat, Aug 26, 2017 at 08:31:30PM +0800, Dr. ERDI Gergo via llvm-dev wrote:
> This trips up the following assertion in CodeGen/SelectionDAG/
SelectionDAGBuilder.cpp:
>
>   if (I.getAlignment() < VT.getSizeInBits() / 8)
>     report_fatal_error("Cannot generate unaligned atomic load");
>
>
> I've tried commenting out the check and llc finishes, generating
> not-obviously-wrong machine code, so there doesn't seem to be anything
> further downstream breaking because of this.
>
> So my questions are:
>
> * What is the purpose of this assertion?

Existing targets so far simply don't support unaliged atomic ops. That's
why it hasn't been refactored into a target information hook.

Joerg
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170826/f266f31f/attachment.html>


More information about the llvm-dev mailing list