This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] NFC: Cleanup isAArch64FrameOffsetLegal
ClosedPublic

Authored by sdesmalen on Mar 21 2019, 4:34 AM.

Details

Summary

Cleanup isAArch64FrameOffsetLegal by:

  • Merging the large switch statement to reuse AArch64InstrInfo::getMemOpInfo().
  • Using AArch64InstrInfo::getUnscaledLdSt() to determine whether an instruction has an unscaled variant.
  • Simplifying the logic that calculates the offset to fit the immediate.

Diff Detail

Event Timeline

sdesmalen created this revision.Mar 21 2019, 4:34 AM
efriedma added inline comments.
lib/Target/AArch64/AArch64InstrInfo.cpp
2129

It seems unlikely to me that this actually has no effect on the generated code; getMemOpInfo has other callers.

3277

The math here is weird... could you check whether the offset is valid in some more obvious way?

lib/Target/AArch64/AArch64InstrInfo.h
92

This could use a better name, to reflect how you expect it to be used, e.g. getLoadStoreImmIdx? (It probably isn't right for all instructions...)

sdesmalen marked 3 inline comments as done.Mar 22 2019, 10:24 AM
sdesmalen added inline comments.
lib/Target/AArch64/AArch64InstrInfo.cpp
2129

Good spot! Having a look how this function is used (mostly in getOutliningCandidateInfo and also getMemOperandWithOffset, which is then used in e.g. MachineSink), it will probably be a bit awkward to make tests for it. So just to double check, are you suggesting to pull out these changes to a separate patch that adds tests for different users/uses of this function, or are you suggesting to drop the 'NFC' from the description?

3277

Do you mean any lines in specific? Or the entire way we calculate (Emittable)Offset and Remainder here?

lib/Target/AArch64/AArch64InstrInfo.h
92

You're right, this is a bit of misnomer. getLoadStoreImmIdx sounds more appropriate! I'll change that in the next revision.

sdesmalen marked 3 inline comments as not done.Mar 22 2019, 10:26 AM

(not sure why Phabricator marked these comments as 'done' since they're not done yet)

paquette added inline comments.Mar 22 2019, 10:53 AM
lib/Target/AArch64/AArch64InstrInfo.cpp
1719

Maybe this could use a better name? It's unintuitive to return 0 when the name seems to imply that you expect a scaled load/store opcode. I would expect this to be unreachable with the current name.

3235

Probably worth a comment saying that this can be 0 here.

lib/Target/AArch64/AArch64InstrInfo.h
87

Probably good to note that this returns 0 if the opcode doesn't correspond to a scaled load or store.

efriedma added inline comments.Mar 22 2019, 12:02 PM
lib/Target/AArch64/AArch64InstrInfo.cpp
2129

It tends to be easier for everyone when non-functional changes are split from functional changes, in cases where it isn't too difficult.

I'm fine committing an "obvious" change like this without a test, though; writing a separate test for each possible opcode just to reproduce the information here isn't really productive.

sdesmalen marked 13 inline comments as done.
  • This patch now uses Optional<unsigned> for getUnscaledLdSt()
  • Separate out the non-functional changes from the functional change (the added cases in AArch64InstrInfo::getMemOpInfo)
  • Some more simplification of the arithmetic in isAArch64FrameOffsetLegal.
sdesmalen added inline comments.Mar 25 2019, 10:18 AM
lib/Target/AArch64/AArch64InstrInfo.cpp
1719

I've used Optional<unsigned> to make it more clear to the caller that the value can be invalid. Do you think the name-change is still needed?

2129

Right, I have now split the 'functional change' (the added case statements) into a separate patch that I plan to commit to trunk directly.

3277

I have refactored/simplified the math a bit more, let me know if you think this clarified things.

paquette added inline comments.Mar 25 2019, 10:32 AM
lib/Target/AArch64/AArch64InstrInfo.cpp
1719

I think that the optional clears things up!

efriedma added inline comments.Mar 25 2019, 12:44 PM
lib/Target/AArch64/AArch64InstrInfo.cpp
3269

It's still a little strange to compute "Offset" here, then only use the computed value to check whether it's equal to zero. A separate variable probably makes more sense.

sdesmalen marked an inline comment as done.Mar 25 2019, 1:28 PM
sdesmalen added inline comments.
lib/Target/AArch64/AArch64InstrInfo.cpp
3269

Note that Offset is passed by reference, so is used as an output variable as well.
isAArch64FrameOffsetLegal returns whether the immediate can be used to handle the offset, either in full or partially. In the latter case where the instruction can't fully handle the offset using the immediate, the remaining offset (in bytes) that needs to be handled differently is again stored in Offset.

efriedma accepted this revision.Mar 25 2019, 2:00 PM

LGTM

lib/Target/AArch64/AArch64InstrInfo.cpp
3269

Oh, right... it's fine then, I guess. (Maybe could use a few more comments, but I'm not sure where, exactly.)

This revision is now accepted and ready to land.Mar 25 2019, 2:00 PM
sdesmalen closed this revision.Mar 27 2019, 10:24 AM

Closing this patch manually. I accidentally changed the last digit to be D59636 when I committed this patch :)