[llvm-dev] Folding zext from i1 into PHI nodes with only zwo incoming values.

[Sanjay Patel via llvm-dev]

I'm looking at a similar problem in:
https://reviews.llvm.org/D28625

Does that patch make any difference on the cases that you are looking at?

Instead of avoiding ShouldChangeType with zext as a special-case opcode, it
might be better to treat i1 as a special-case type. There's no way to avoid
i1 in IR, so we might as well allow transforming to that type?

I'm not sure yet, but there's a chance that change might induce problems
(infinite loops) with this:
https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/
InstCombineSimplifyDemanded.cpp#L374


On Sun, Jan 29, 2017 at 3:09 PM, Björn Steinbrink via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> AFAICT there are two places where zext instructions may get folded into
> PHI nodes. One is FoldPHIArgZextsIntoPHI and the other is the more generic
> FoldPHIArgOpIntoPHI. Now, the former only handles PHIs with more than 2
> incoming values, while the latter only handles casts where the source type
> is legal.
>
> This means that for an PHI node with two incoming i8 values, both
> resulting from `zext i1 * to i8` instructions, both of these functions will
> refuse to actually fold the zext into the PHI, while the same operation
> would be performed if there were three or more arms. We noticed this
> because we saw a optimization regression when a function got specialized
> and the PHI node only had two incoming values left.
>
> Since I'm not fully aware of any implications this might have, I wonder
> what is the right way to fix this? Looking at FoldPHIArgZextsIntoPHI, it
> seems that making the check for `ShouldChangeType` in FoldPHIArgOpIntoPHI
> conditional on the cast instruction not being a zext instruction. Does that
> sound right, or am I missing something here?
>
> Thanks
> Björn
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170130/a37b2069/attachment.html>