This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Allow LI with symbol difference as constant
ClosedPublic

Authored by jobnoorman on Oct 14 2022, 7:28 AM.

Details

Summary

This patch lets the assembler accept code like the following:

.Lbuf: ...
.set .Lbuf_len, . - .Lbuf
li a0, .Lbuf_len

It works by translating such instances of LI into an ADDI and inserting
the correct constant value via a new fixup.

Note that this means that the constant value is restricted to 12 bits
since we cannot insert new instructions during the relaxation stage.
Binutils seems to have the same restriction though.

This patch also fixes a small issue where the SMLoc of an LI wasn't
propagated when translated to ADDI. While this is technically unrelated
to the main functionality of this patch, it improves error messages
related to the new use of LI.

This patch does _not_ allow I-type instructions to take such symbolic
constants as well. While technically possible (and allowed by binutils),
it's probably better to implement this in another patch.

Fixes #57461

Diff Detail

Event Timeline

jobnoorman created this revision.Oct 14 2022, 7:28 AM
jobnoorman requested review of this revision.Oct 14 2022, 7:28 AM
jobnoorman updated this revision to Diff 495445.Feb 7 2023, 2:47 AM

Rebase on current main.

(The previous version failed to apply since d178bd2caf079b694d94b3fc94b1b83e25568ecd)

reames added a subscriber: reames.Feb 7 2023, 10:54 AM
reames added inline comments.
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
3256

Please separate this change as it's own diff so I can review it separately.

reames added inline comments.Feb 7 2023, 10:58 AM
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
3256

It also looks like we have the same problem in emitAuipcInstPair used for a bunch of the other cases.

jrtc27 added inline comments.Feb 7 2023, 11:34 AM
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
3256

This would probably be nicer if MCInstBuilder could take an SMLoc in its constructor and/or had a setLoc method. There are surely many cases of backends throwing this away as a result... though this is AsmParser so debug info is barely a thing.

jrtc27 added a comment.Feb 7 2023, 1:19 PM

This seems rather limited in use...

Also nothing's testing the error case.

llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
3256

Oh right SMLoc not SDLoc, so not debug info at least

llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp
56

Hm, this is the only fixup that doesn't correspond to a relocation?

430

Don't you still need to mask this so the high bits of negative values get cleared?

This seems rather limited in use...

I agree this doesn't have a very high urgency but this feature was requested here. Note that the GNU assembler also supports it.

Also nothing's testing the error case.

Right, I forgot about that. Will add a test in the next version!

llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
3256

Please separate this change as it's own diff so I can review it separately.

Will do!

llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp
56

I suppose it is. Is this a problem?

430

Right, will fix!

jobnoorman updated this revision to Diff 495827.Feb 8 2023, 6:35 AM

Address comments:

  • Remove setting location of generated addi
  • Mask high bits of fixup value
  • Add test for error case
asb added a comment.Mar 8 2023, 2:08 AM

Could you please update the patch description to say "Fixes #57461" or similar?

I think all the review comments are addressed and I don't have additional feedback - the only open line of discussion I think was about how fixup_riscv_12_i is the only fixup that can never result in a relocation (as pointed out by @jrtc27). That's true, but I also can't see an alternative way of handling it or any real disadvantage of this - it logically _is_ a fixup. Do you see an alternative approach, or was it more that you think it would make sense to adjust the naming so it's clearer it doesn't have a matching relocation?

jobnoorman edited the summary of this revision. (Show Details)Mar 8 2023, 2:29 AM
asb added a comment.Mar 21 2023, 3:26 AM

Could you please update the patch description to say "Fixes #57461" or similar?

I think all the review comments are addressed and I don't have additional feedback - the only open line of discussion I think was about how fixup_riscv_12_i is the only fixup that can never result in a relocation (as pointed out by @jrtc27). That's true, but I also can't see an alternative way of handling it or any real disadvantage of this - it logically _is_ a fixup. Do you see an alternative approach, or was it more that you think it would make sense to adjust the naming so it's clearer it doesn't have a matching relocation?

Rereading this, I wasn't very clear who I was directing my question to - I meant to direct it at @jrtc27 - what do you think?

asb added a comment.Mar 28 2023, 3:20 AM

Could you please update the patch description to say "Fixes #57461" or similar?

I think all the review comments are addressed and I don't have additional feedback - the only open line of discussion I think was about how fixup_riscv_12_i is the only fixup that can never result in a relocation (as pointed out by @jrtc27). That's true, but I also can't see an alternative way of handling it or any real disadvantage of this - it logically _is_ a fixup. Do you see an alternative approach, or was it more that you think it would make sense to adjust the naming so it's clearer it doesn't have a matching relocation?

Rereading this, I wasn't very clear who I was directing my question to - I meant to direct it at @jrtc27 - what do you think?

@jrtc27 - pinging to check you're happy landing this patch. Thanks!

Friendly ping.

asb accepted this revision.May 16 2023, 10:30 AM

I believe all review comments have been addressed, it LGTM, and I've pinged multiple times to check the previous reviewer concurs comments were addressed. So I think you're good to land this - thanks.

This revision is now accepted and ready to land.May 16 2023, 10:30 AM
This revision was automatically updated to reflect the committed changes.
evandro removed a subscriber: evandro.May 17 2023, 3:51 PM