[llvm-dev] Folding zext from i1 into PHI nodes with only zwo incoming values.
Sanjay Patel via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 30 11:20:32 PST 2017
I'm looking at a similar problem in:
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:
On Sun, Jan 29, 2017 at 3:09 PM, Björn Steinbrink via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev