This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Fix encoding for lsl #12 in add/sub immediates
ClosedPublic

Authored by rovka on Aug 26 2016, 9:31 AM.

Details

Summary

Whenever an add/sub immediate needs a fixup, we set that immediate field to zero,
which is correct, but we also set the shift bits to zero, which is not true for
instructions that use lsl #12. This patch makes sure that if lsl #12 was used,
it will appear in the encoding of the instruction.

Diff Detail

Repository
rL LLVM

Event Timeline

rovka updated this revision to Diff 69388.Aug 26 2016, 9:31 AM
rovka retitled this revision from to [AArch64] Fix encoding for lsl #12 in add/sub immediates.
rovka updated this object.
rovka added reviewers: t.p.northover, compnerd.
rovka added subscribers: llvm-commits, rengolin, psmith.
rovka added a comment.Aug 26 2016, 9:40 AM

I checked with gas and it does the same thing for :tprel_hi12:, :lo12: and label arithmetic.

From an ELF perspective I think that this is the right thing to do. The only OpenSource ELF linker I know of that implements R_AARCH64_TLSLE_ADD_TPREL_HI12 does not touch the shift field when resolving the relocation. It is possible to write a test case that gives an incorrect result when there is a large enough amount of tls for the tprel_hi12 to be needed.

One thing I note that the GNU assembler will do is set the shift value if the result of the expression can be represented with the shift, but not without it. For example
.L1:
.space 0x10000
.L2:
From my reading of the code it seems like we'll fault this as out of range. If I'm right it would be nice to support this, but I don't think it necessarily needs to be done as part of this one.

lib/Target/AArch64/MCTargetDesc/AArch64MCCodeEmitter.cpp
266 ↗(On Diff #69388)

Line 256 has an almost identical (ShiftVal == 0 ? 0 : (1 << 12)), it could be worth being consistent with this line although I don't have a particularly strong opinion.

From my reading of the code it seems like we'll fault this as out of range. If I'm right it would be nice to support this, but I don't think it necessarily needs to be done as part of this one.

Yes, this is an interesting enhancement, and should be reasonably simple. But not for this patch, I agree.

rovka added a comment.Aug 30 2016, 4:31 AM

From my reading of the code it seems like we'll fault this as out of range. If I'm right it would be nice to support this, but I don't think it necessarily needs to be done as part of this one.

Yes, this is an interesting enhancement, and should be reasonably simple. But not for this patch, I agree.

I don't know if it's that simple. The logic that actually computes the value to be stored in the immediate is part of the fixup handling, and at that point we're really only concerned with those 12 bits that represent the immediate (the shift bit is not part of the fixup). I can't think of a good way to handle this without having to extend the fixup to cover the shift bit as well, which is kind of awkward because then we'd have to express the shift as part of Expr (so we'd be creating a new shift expression with the original Expr as an operand, and then parsing that as part of the fixup). I'm not sure it's worth the effort.

Also, I think it would be difficult to maintain assembly that relies on this property: .space 0x1000 works, but .space 0x1000 - 4 gives an "immediate out of range" error, which just looks surprising unless you figure out to inspect the encodings.

Just my 2 cents.

Also, I think it would be difficult to maintain assembly that relies on this property: .space 0x1000 works, but .space 0x1000 - 4 gives an "immediate out of range" error, which just looks surprising unless you figure out to inspect the encodings.

You'd be surprised how some people use the assembler... :)

But that's for another patch.

I also agree with Peter. But would be good to get some Darwin perspective. @t.p.northover?

t.p.northover edited edge metadata.Sep 12 2016, 5:18 AM

Seems basically reasonable. It would probably be better if we diagnosed attempts that ended up with a relocation (as far as I can see there's no good reason to write those forms). But since we don't do that now, it probably needn't be in this patch.

rovka added a comment.Sep 14 2016, 3:48 AM

Thanks for having a look. Is it ok to commit? (With Peter's nit addressed)

rengolin accepted this revision.Sep 19 2016, 2:21 AM
rengolin added a reviewer: rengolin.

Sorry it took so long, this fell out of my radar. I think we're all in agreement. LGTM.

Thanks!
--renato

This revision is now accepted and ready to land.Sep 19 2016, 2:21 AM
This revision was automatically updated to reflect the committed changes.