This is an archive of the discontinued LLVM Phabricator instance.

Standardize how we check for legality of frame realignment
AbandonedPublic

Authored by reames on Jul 17 2019, 5:10 PM.

Details

Summary

We currently have three ways to check whether a stack can be realigned. TargetFrameInfo, MachineFrameInfo, and TargetRegisterInfo. This patch attempts to standardize on one of them (TRI) as the source of truth.

This patch does change behaviour in corner-cases. Previously, an overaligned static alloc in a no-realign-stack function had it's alignment silently ignored. Now, the frame isn't stack object isn't dynamically aligned on entry, but instead becomes a variable sized frame around the alloca scope. (i.e. it's treated as a dynamic alloca)

Diff Detail

Event Timeline

reames created this revision.Jul 17 2019, 5:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 17 2019, 5:10 PM
reames updated this revision to Diff 210468.Jul 17 2019, 5:29 PM

Highlight the change in behaviour for over aligned allocas w/o stack realignment.

The result is a bit counter intuitive. We generate a variable size frame, but not one with realignment. Not really sure this is any better, but at least it's consistent with frames which aren't realignable as a target property?

reames edited the summary of this revision. (Show Details)Jul 17 2019, 5:45 PM

I was independently looking to this part and came up with essentially same change. The only difference is that I chose MachineFrameInfo as source of "truth". Not really sure which one is better though...

reames abandoned this revision.Oct 15 2021, 11:57 AM

Abandoning an old review I'm not going to return to any time soon.