This is an archive of the discontinued LLVM Phabricator instance.

StackSlotColoring: Decide colors per stack ID
ClosedPublic

Authored by arsenm on Apr 23 2018, 8:12 AM.

Details

Summary

I thought I fixed this in r308673, but that fix was
very broken. The assumption that any frame index can be used
in place of another was more widespread than I realized.
Even when stack slot sharing was disabled, this was still
replacing frame index uses with a different ID with a different
stack slot.

Really fix this by doing the coloring per-stack ID, so all of
the coloring logically done in a separate namespace. This is a lot
simpler than trying to figure out how to change the color if
the stack ID is different.

Diff Detail

Event Timeline

arsenm created this revision.Apr 23 2018, 8:12 AM

Disclaimer: I haven't never looked at how this pass actually works so take my comments with a grain of salt!

Hi Matt,

If we do the tracking per StackID, how do we make sure the UsedColors don't overlaps between conflicting StackIDs?

Basically, I am not saying the patch is wrong, instead I am looking at what kind of assert/verify we could add to make sure it doesn't happen going down the path of the data not being "globally sync-ed".

Cheers,
-Quentin

Disclaimer: I haven't never looked at how this pass actually works so take my comments with a grain of salt!

Hi Matt,

If we do the tracking per StackID, how do we make sure the UsedColors don't overlaps between conflicting StackIDs?

Basically, I am not saying the patch is wrong, instead I am looking at what kind of assert/verify we could add to make sure it doesn't happen going down the path of the data not being "globally sync-ed".

Cheers,
-Quentin

The set of used colors is tracked separately for each one (i.e. UsedColors is now a vector of tracked colors per stack ID), as is the rest of the machinery. I added some assertions in the backend which catch some of these, and one in this patch. It's possible there's a better place for the assert.

This patch fixes one of the issues with Luxmark I am looking into.

The concept looks like the right thing, and the code looks good to me. I feel I don't have the experience in this area to officially sign off on it with a "LGTM", but I have no qualms about this after reviewing it.

yaxunl added a subscriber: yaxunl.Jun 20 2018, 3:57 AM

The patch fixes the issue I found in Blender application

tpr added a subscriber: tpr.Jun 21 2018, 2:09 AM
tpr added inline comments.
lib/CodeGen/StackSlotColoring.cpp
303

As you pointed out, my review D48416 tries to fix the same problems.

Color is now per-StackID, right? But the color is used as the new frame index and written back to the operands. So how does this assert, or the assert at AMDGPU/SIFrameLowering.cpp:694, or anything that uses the new frame index (the color) to index into MFI->StackObjects, work now?

arsenm added inline comments.Jun 21 2018, 5:57 AM
lib/CodeGen/StackSlotColoring.cpp
303

IIRC I tried something similar to your approach and it didn't work.

If I remember how this works, the color can only be determined from the set of used frame indexes already (which are now tracked disjointly)

tpr accepted this revision.Jun 22 2018, 10:47 AM

Oh right, I get it now. The colors are disjoint, and it will only allocate a slot to another slot's color if it is the same StackID.

LGTM, except the test has slightly rotted and needs s/di-/debug-info-/g

This revision is now accepted and ready to land.Jun 22 2018, 10:47 AM
arsenm closed this revision.Jun 25 2018, 9:10 AM

r335488