This is an archive of the discontinued LLVM Phabricator instance.

Relax unaligned access assertion when type is byte aligned
ClosedPublic

Authored by dylanmckay on Nov 12 2017, 2:38 AM.

Details

Summary

This relaxes an assertion inside SelectionDAGBuilder which is overly
restrictive on targets which have no concept of alignment (such as AVR).

In these architectures, all types are aligned to 8-bits.

After this, LLVM will only assert that accesses are aligned on targets
which actually require alignment.

This patch follows from a discussion on llvm-dev a few months ago
http://llvm.1065342.n5.nabble.com/llvm-dev-Unaligned-atomic-load-store-td112815.html

Event Timeline

dylanmckay created this revision.Nov 12 2017, 2:38 AM
dylanmckay edited the summary of this revision. (Show Details)Nov 12 2017, 9:36 PM
nemanjai edited edge metadata.Nov 14 2017, 11:55 AM

A couple of general comments...
I'm not a fan of modifying the ABI of DataLayout for this. Seems that we can just compare the ABI alignment against 1 at the call site. But I also wonder if it would suffice to simply check that the load instruction's alignment is less than the ABI alignment for that type
if (I.getAlignment() < DL.getABITypeAlignment(Ty))

However, that makes the additional assumption that targets can handle atomic loads with an alignment that is the same as the ABI alignment for that type. I believe this is a safe assumption, but perhaps that should be checked with the target maintainers. In either case, I think a quick check with the target maintainers would be good.

However, that makes the additional assumption that targets can handle atomic loads with an alignment that is the same as the ABI alignment for that type.

This is not a safe assumption. For example, 32-bit x86 supports atomic 64-bit loads with native alignment, but the ABI alignment of i64 is only 32 bits. (It might be technically possible to synthesize an unaligned atomic load on x86, but it's not something we try to do.)

include/llvm/IR/DataLayout.h
429 ↗(On Diff #122601)

This helper is more likely to be confusing than actually helpful.

lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
4145

I would prefer to have a target hook here, so we don't end up miscompiling or generating some obscure instruction selection failure for a target that isn't expecting this.

dylanmckay updated this revision to Diff 125903.Dec 7 2017, 1:43 AM
dylanmckay marked 2 inline comments as done.
  • Prefer explicitly-enabled TLI options rather than making assumptions based on data layout
  • Remove misplaced functions on DataLayout

Thanks for the feedback @nemanjai and @efriedma

dylanmckay updated this revision to Diff 125905.Dec 7 2017, 1:49 AM

Remove unneeded modifications to the diff left from the last update

efriedma accepted this revision.Dec 8 2017, 1:05 PM

LGTM

This revision is now accepted and ready to land.Dec 8 2017, 1:05 PM
This revision was automatically updated to reflect the committed changes.