This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Add atomic.fence instruction
ClosedPublic

Authored by aheejin on Aug 27 2019, 3:33 AM.

Details

Summary

This adds atomic.fence instruction:
https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#fence-operator

And we now emit the new atomic.fence instruction for multithread
fences, rather than the prevous atomic.rmw hack.

Event Timeline

aheejin created this revision.Aug 27 2019, 3:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 27 2019, 3:33 AM
aheejin retitled this revision from Add atomic.fence instruction to [WebAssembly] Add atomic.fence instruction.Aug 27 2019, 3:33 AM
aheejin updated this revision to Diff 217356.Aug 27 2019, 3:58 AM
  • Insert fence in the ascending order of opcode
dschuff accepted this revision.Aug 27 2019, 8:44 AM
dschuff added inline comments.
llvm/test/CodeGen/WebAssembly/atomic-fence.ll
7

This line can be removed.

34

how about CHECK-NOT: fence to catch any kind of fence output?
Even better, could we also come up with some sequence of instructions that would otherwise be reordered (e.g. by register stackification) that the fence would prevent?

This revision is now accepted and ready to land.Aug 27 2019, 8:44 AM
aheejin updated this revision to Diff 217632.Aug 28 2019, 6:52 AM
aheejin marked an inline comment as done.
  • Address comments
aheejin updated this revision to Diff 217634.Aug 28 2019, 6:53 AM
aheejin marked an inline comment as done.
  • Remove a stray line
Harbormaster completed remote builds in B37436: Diff 217634.
aheejin updated this revision to Diff 217640.Aug 28 2019, 7:00 AM
aheejin marked an inline comment as done.
  • Fixed comments a little
llvm/test/CodeGen/WebAssembly/atomic-fence.ll
34

how about CHECK-NOT: fence to catch any kind of fence output?

CHECK-NOT: fence doesn't work because it accidentally matches with .functype singlethread_fence () -> () in the output. Added CHECK-NOT: atomic-fence additionally.

Even better, could we also come up with some sequence of instructions that would otherwise be reordered (e.g. by register stackification) that the fence would prevent?

I think it is not easy to show exactly that in this ll test... Added a mir test for that. (The reason I used atomic.notify is, that's one of the rare, maybe the only, instructions that returns a value and has a side effect that's not a trap, which is the condition that satisfies this line.)

great, LGTM!

This revision was automatically updated to reflect the committed changes.