[PATCH] D12965: [InstCombine] shrink switch conditions better (PR24766)

Sanjay Patel via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 14 11:41:52 PDT 2016


spatel added a comment.

In http://reviews.llvm.org/D12965#457693, @majnemer wrote:

> In http://reviews.llvm.org/D12965#457687, @spatel wrote:
>
> > In http://reviews.llvm.org/D12965#457658, @majnemer wrote:
> >
> > > Hmm.  My understanding was that InstCombine was not supposed to create IR with illegal types if it could help it.
> >
> >
> > Do we state that anywhere? Should we make an exception for cases where we know that we have a fixup in a later pass (as we do for this in CGP)?
> >
> > I was proceeding based on Hal's earlier comment:
> >  "We should shrink aggressively for our canonical form because smaller types convey the most information at the IR level."
>
>
> https://github.com/llvm-mirror/llvm/blob/a2bdb6de81cd1de9daaeac9fa8bd24b6e0a48263/lib/Transforms/InstCombine/InstructionCombining.cpp#L91


Ha...I should've remembered that. I added the alternate flavor of that function for the earlier/weaker version of *this* patch!
So then we're on to my 2nd question: we have a safety mechanism in place for this transform; does that change the outcome?
I understand the general reluctance for weird types given the disaster potential, but I don't see the downside for this specific case.

Note that we already got SimplifyCFG to remove the dead case for the example in PR24766, but I wonder if this transform might come into play for something like PR27555:
https://llvm.org/bugs/show_bug.cgi?id=27555


http://reviews.llvm.org/D12965





More information about the llvm-commits mailing list