[llvm-dev] Unaligned atomic load/store

[Nemanja Ivanovic via llvm-dev]

Not to put words in Joerg's mouth, but he kind of alluded to a possible way
forward.
You might want to define a target hook (say in Target Lowering) for say
`allowsUnalignedAtomicMemOps()` that would return `false` on all targets
but yours. Of course, you should definitely investigate whether there is a
reason for this diagnostic (i.e. whether some other passes require natural
alignment).

Another thing I find useful is using `svn blame` on the file in question to
see what revision the diagnostic was added in. Chances are the commit
message or the associated review will have some info on why it was needed.

On Sat, Aug 26, 2017 at 4:50 PM, Dr. ÉRDI Gergő via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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/Selection
> DAGBuilder.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
>
>
>
> _______________________________________________
> 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/20170829/18766b23/attachment.html>