This is an archive of the discontinued LLVM Phabricator instance.

[NFC][CodeGen] Separate TargetRegisterInfo needsStackRealignment and canRealignStack
ClosedPublic

Authored by tmatheson on Mar 16 2021, 9:09 AM.

Details

Summary

Currently needsStackRealignment returns false if canRealignStack returns false. This means that the behavior of needsStackRealignment does not correspond to it's name and description; a function might need stack realignment, but if it is not possible then this function returns false. Furthermore, needsStackRealignment is not virtual and therefore some backends have made use of canRealignStack to indicate whether a function needs stack realignment.

This patch attempts to clarify the situation by separating them:

  • Make needsStackRealignment virtual so that backends can override it
  • Override needsStackRealignment rather than canRealignStack in SIRegisterInfo
  • Update some call sites of needsStackRealignment (where backend tests were failing). Some of these may not be necessary.

This change will make it easier in a future change to handle the case where we need to realign the stack but can't do so (for example when the register allocator creates an aligned spill after the frame pointer has been eliminated).

Diff Detail

Event Timeline

tmatheson created this revision.Mar 16 2021, 9:09 AM
tmatheson requested review of this revision.Mar 16 2021, 9:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 16 2021, 9:09 AM
tmatheson updated this revision to Diff 331080.Mar 16 2021, 1:20 PM

SparcFrameLowering: fix the check for failure to realign that was causing the test failure, and remove the old comment explaining needStackRealignment behavior.

arsenm added inline comments.Mar 24 2021, 5:44 AM
llvm/include/llvm/CodeGen/TargetRegisterInfo.h
917

I've found this pair of functions confusing before. I think the naming and having to call both in most situations is still confusing. I'm also not sure why this is in TargetRegisterInfo, and not TargetFrameLowering.

needsStackRealignment feels too strong given that the target can say we're not realigning the stack anyway. How about something like hasImpliedStackRealignment? And a partner function to call both called something like hasStackRealignment?

needsStackRealignment feels too strong given that the target can say we're not realigning the stack anyway. How about something like hasImpliedStackRealignment? And a partner function to call both called something like hasStackRealignment? And a partner function to call both called something like hasStackRealignment?

How about the following naming?

  • shouldRealignStack - true if there is any reason the stack should be realigned
  • canRealignStack - true if we are still able to realign the stack (e.g. we can still reserve/have reserved a frame pointer)
  • hasStackRealignment = shouldRealignStack && canRealignStack (not target customisable, for now at least)

Then targets are free to error on shouldRealignStack && !canRealignStack if appropriate, or ignore/work around it.

needsStackRealignment feels too strong given that the target can say we're not realigning the stack anyway. How about something like hasImpliedStackRealignment? And a partner function to call both called something like hasStackRealignment? And a partner function to call both called something like hasStackRealignment?

How about the following naming?

  • shouldRealignStack - true if there is any reason the stack should be realigned
  • canRealignStack - true if we are still able to realign the stack (e.g. we can still reserve/have reserved a frame pointer)
  • hasStackRealignment = shouldRealignStack && canRealignStack (not target customisable, for now at least)

Then targets are free to error on shouldRealignStack && !canRealignStack if appropriate, or ignore/work around it.

Seems reasonable

tmatheson updated this revision to Diff 334109.Mar 30 2021, 4:44 AM

Update with new names: shouldRealignStack/canRealignStack/hasStackRealignment

arsenm accepted this revision.Mar 30 2021, 6:28 AM
This revision is now accepted and ready to land.Mar 30 2021, 6:28 AM

It looks like the clang-tidy CI is broken (running clang tidy on backends that have been modified but are not built?). The rest of the CI looks ok so I will merge this.

This revision was landed with ongoing or failed builds.Mar 30 2021, 9:31 AM
This revision was automatically updated to reflect the committed changes.