This is an archive of the discontinued LLVM Phabricator instance.

[ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors
ClosedPublic

Authored by morisset on Sep 10 2014, 5:39 PM.

Details

Summary

I had only tested this code for ARMv7 and ARMv8. This patch adds several
fallback paths if the processor does not support dmb ish:

  • dmb sy if a cortex-M with support for dmb
  • mcr p15, #0, r0, c7, c10, #5 for ARMv6 (special instruction equivalent to a DMB)
  • call to __sync_synchronize otherwise.

These fallback paths were chosen based on the code for fence seq_cst.

Thanks to luqmana for having noticed this bug.

Diff Detail

Repository
rL LLVM

Event Timeline

morisset updated this revision to Diff 13568.Sep 10 2014, 5:39 PM
morisset retitled this revision from to [ARM, Fix] Fix emitLeading/TrailingFence on old ARM processors.
morisset updated this object.
morisset edited the test plan for this revision. (Show Details)
morisset added reviewers: jfb, t.p.northover, luqmana.
morisset added a subscriber: Unknown Object (MLST).
luqmana edited edge metadata.Sep 12 2014, 10:06 AM

Looks fine to me but I'm not really all that familiar with this code.

jfb added inline comments.Sep 12 2014, 10:13 AM
lib/Target/ARM/ARMISelLowering.cpp
11003 ↗(On Diff #13568)

Is there a test for this call? We need to make sure it actually calls what you expect.

morisset updated this revision to Diff 13645.Sep 12 2014, 10:45 AM
morisset edited edge metadata.

Thanks jf for catching this forgotten test!

It turned out that this code is dead, as these subtargets completely avoid this
code path anyway. I have replaced it by llvm_unreachable, and it is tested by
the ARMv4 test in atomic-load-store.

jfb edited edge metadata.Sep 12 2014, 10:51 AM
In D5304#7, @morisset wrote:

Thanks jf for catching this forgotten test!

It turned out that this code is dead, as these subtargets completely avoid this
code path anyway. I have replaced it by llvm_unreachable, and it is tested by
the ARMv4 test in atomic-load-store.

Is there a test that demonstrates the result of the other code path? I can't find code that generates the barrier in the tests, so it would be nice to add (maybe in a different change).

There is no barrier generated by the other path, the entire operation (store/load/rmw/whatever) is turned into a libcall on these old processors. It is tested (summarily) at the end of atomic-load-store.ll at least.

morisset updated this revision to Diff 13767.Sep 16 2014, 5:30 PM
morisset edited edge metadata.

Rebase on trunk.

jfb accepted this revision.Sep 16 2014, 10:29 PM
jfb edited edge metadata.
In D5304#10, @morisset wrote:

There is no barrier generated by the other path, the entire operation (store/load/rmw/whatever) is turned into a libcall on these old processors. It is tested (summarily) at the end of atomic-load-store.ll at least.

Sounds good, lgtm.

This revision is now accepted and ready to land.Sep 16 2014, 10:29 PM
morisset closed this revision.Sep 17 2014, 10:51 AM
morisset updated this revision to Diff 13791.

Closed by commit rL217965 (authored by @morisset).