This is an archive of the discontinued LLVM Phabricator instance.

GlobalISel: Handle llvm.read_register
ClosedPublic

Authored by arsenm on Sep 15 2019, 7:27 PM.

Details

Summary

SelectionDAG has a bunch of machinery to defer this to selection time
for some reason. Just directly emit a copy during IRTranslator. The
x86 usage does somewhat questionably check hasFP, which could depend
on the whole function being at minimum translated.

This does lose the convergent bit if the callsite had it, which may be
a problem. We also lose that in general for intrinsics, which may also
be a problem.

Diff Detail

Event Timeline

arsenm created this revision.Sep 15 2019, 7:27 PM

Added some context comments in D67601.

For this one: why only AMDGPU tests? Would be good to have at least ARM32/64, since they should be working with GlobalIsel, no?

Not sure what's the difference between buffer_store_dword and flat_store_dword to make a comment on that change.

Added some context comments in D67601.

For this one: why only AMDGPU tests? Would be good to have at least ARM32/64, since they should be working with GlobalIsel, no?

One target is sufficient for new feature additions

Not sure what's the difference between buffer_store_dword and flat_store_dword to make a comment on that change.

GlobalISel doesn't yet implement the buffer_store path for older targets, but it's irrelevant for the actual test

rengolin accepted this revision.Sep 26 2019, 9:45 AM

For this one: why only AMDGPU tests? Would be good to have at least ARM32/64, since they should be working with GlobalIsel, no?

One target is sufficient for new feature additions

Fair enough. LGTM, thanks!

PS: @rovka, do you know if we have similar tests on the Arm side? Would be good to have some, too.

This revision is now accepted and ready to land.Sep 26 2019, 9:45 AM
arsenm closed this revision.Sep 30 2019, 7:08 PM

r373294

Even though this was reverted, I'm going to necromance it to point out an issue with the approach wrt AArch64 in the inline comments.

Maybe a G_READ_REGISTER/G_WRITE_REGISTER opcode would be a better approach?

lib/CodeGen/GlobalISel/IRTranslator.cpp
1529

TLI->getRegisterByName can't handle sysregs on the AArch64 side, since they're modelled as immediate operands. So, this approach can't work for AArch64.

(see llvm/test/CodeGen/AArch64/special-reg.ll for an example)

rengolin added inline comments.Oct 18 2019, 10:06 AM
lib/CodeGen/GlobalISel/IRTranslator.cpp
1529

By design, they can only get the stack pointer, I think on any target. It should be an assembler error otherwise.

paquette added inline comments.Oct 18 2019, 10:49 AM
lib/CodeGen/GlobalISel/IRTranslator.cpp
1529

I don't think that's true in AArch64. E.g.:

https://reviews.llvm.org/D53115

The test added there uses read/write_register to access other special registers. This change made the test added there fail.

There's also the special-reg.ll test I mentioned above which has stuff like this:

%reg = call i64 @llvm.read_register.i64(metadata !1)
...
!1 = !{!"daif"}

Which is supposed to produce this (which does not involve SP):

mrs x0, DAIF

So I don't think that the stack pointer is the only thing we have to think about here. (Unless I'm seriously misunderstanding something, which is entirely possible. :P)

arsenm marked an inline comment as done.Oct 18 2019, 10:58 AM
arsenm added inline comments.
lib/CodeGen/GlobalISel/IRTranslator.cpp
1529

We use this for the EXEC mask (with the special consideration that the call site needs to be marked convergent)

rengolin added inline comments.Oct 18 2019, 11:51 AM
lib/CodeGen/GlobalISel/IRTranslator.cpp
1529

Is that exposed to the users? For example, by declaring a register variable asm("daif")?

Writing to such a "variable" would be potentially dangerous, no?

arsenm marked an inline comment as done.Oct 18 2019, 12:07 PM
arsenm added inline comments.
lib/CodeGen/GlobalISel/IRTranslator.cpp
1529

Only through builtins and builtin library functions, not asm variables

rengolin added inline comments.Oct 18 2019, 12:13 PM
lib/CodeGen/GlobalISel/IRTranslator.cpp
1529

Right, sounds good, thanks!