[PATCH] D104264: Fix atomic loads and stores of 64-bit values in non-default address spaces on ARM

Renato Golin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 15 10:30:36 PDT 2021


rengolin added a comment.

Those are great questions! :)

In D104264#2819735 <https://reviews.llvm.org/D104264#2819735>, @koutheir wrote:

> Would this qualify atomic operations in non-default address spaces as undefined behavior?

No. Atomic operations are a red-herring.

The problem here is that a particular handling of 64-bit atomic operations on Arm are creating a pointer bit-cast that fails because they're in different address spaces.

Since implicit bit-casting pointers across address spaces are not allowed, this code in the Arm back-end is "faulty".

Perhaps the fix is to create an `i8*` on the address space of the original pointer?

> The IR is coming from our custom port of the LLVM back-end of GraalVM to ARMv7-A.

I suspected as much.

> Does this mean we should keep the current state as is, and simply never feed the ARM back-end this kind of instructions?

Perhaps. You can lower the address space semantics (checks and cast to the default address space) before it gets to the back-end.

This fixes your problem. It doesn't fix the bug you found, though.

I created a bug for the back-end part of things: https://bugs.llvm.org/show_bug.cgi?id=50721.

Feel free to subscribe, or even send an email to llvm-dev to discuss and hope someone who understands more about address spaces in LLVM chimes in.

Meanwhile, you can avoid the problem by converting address space semantics before it gets to the back-end.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104264/new/

https://reviews.llvm.org/D104264



More information about the llvm-commits mailing list