Page MenuHomePhabricator

[InstCombine] Teach PromoteCastOfAllocation to not insert a bitcast into the middle of a group of allocas
AbandonedPublic

Authored by craig.topper on Thu, May 14, 12:18 PM.

Details

Reviewers
spatel
efriedma
Summary

Alloca's are usually grouped together at the top of the entry block. We shouldn't insert other instructions between them.

Fixes the weird IR seen in the stack coloring pass here http://lists.llvm.org/pipermail/llvm-dev/2020-May/141421.html StackColoring should probably also be fixed to handle this better too, but I didn't look into it any further.

Diff Detail

Event Timeline

craig.topper created this revision.Thu, May 14, 12:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptThu, May 14, 12:18 PM
Herald added a subscriber: hiraditya. · View Herald Transcript

FWIW, I don't think we have the alloca grouping as a rigorous requirement. Without doing that, which basically means teaching the verifier and putting it the lang ref, this might be(come) a long term game of whack-a-mole.

That said, I don't have a problem with the patch, just want to mention that this might not be the way we want to go. I mean, let's go all in on the grouping or not at all.

I'm not sure we really want to go down this path. We can't reliably guarantee that all static allocas are at the beginning of the entry block; this fix will just make it slightly hard to trip over any resulting issues.

FWIW, there's another place in InstCombine that does something like this, simplifyAllocaArraySize in InstCombineLoadStoreAlloca.cpp So I thought maybe this was desired behavior.

FWIW, there's another place in InstCombine that does something like this, simplifyAllocaArraySize in InstCombineLoadStoreAlloca.cpp So I thought maybe this was desired behavior.

I saw multiple places over the years. I also heard from people they think there is some kind of guarantee or canonical form that the allocas are in the beginning and grouped. I don't think there is, e.g., I checked the other day and SROA scans the entire entry block.

Personally, I'd say we need to fix the passes to deal with this. But I do not have a strong opinion.

So for the originally reported issue, it looks like in StackColoring::remapInstructions To is later than From in the basic block. And there's a use of From between them. So when From is replaced with To we create bad IR. So we need to move To to From if From is earlier? Or if there is a user of From that's earlier than To? I think the code does walk all uses of From already.

jdoerfert added a comment.EditedThu, May 14, 2:05 PM

So for the originally reported issue, it looks like in StackColoring::remapInstructions To is later than From in the basic block. And there's a use of From between them. So when From is replaced with To we create bad IR. So we need to move To to From if From is earlier? Or if there is a user of From that's earlier than To? I think the code does walk all uses of From already.

It is not wrong for StackColoring to "just" move allocas to the beginning of a block (first insert point probably), even eagerly. Or, less invasive, maybe something like this:

    const AllocaInst *From = MFI->getObjectAllocation(SI.first);
    const AllocaInst *To = MFI->getObjectAllocation(SI.second);
✚   if (!From->comesBefore(To))                                                                                                                                                                   
✚    const_cast<AllocaInst*>(From)->moveBefore(const_cast<AllocaInst*>(To));

EDIT: Without looking at the rest of the code, the order property is not "directly" tied to the grouping property. So while one might imply the other it seems to be a safer way to really test/ensure the property we need here.

craig.topper abandoned this revision.Sat, May 16, 3:39 PM

Will try to fix stack coloring instead