[PATCH] [SROA] Fold a PHI node if all its incoming values are the same

[hfinkel at anl.gov]

----- Original Message -----
> From: "Jingyue Wu" <jingyue at google.com>
> To: jingyue at google.com, nlewycky at google.com, eliben at google.com, meheff at google.com, chandlerc at gmail.com
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Sunday, July 27, 2014 11:21:24 AM
> Subject: Re: [PATCH] [SROA] Fold a PHI node if all its incoming values are the	same
> 
> Hi Duncan,
> 
> I tried SimplifyPHINode and it worked pretty well. Thanks!
> 
> That makes me consider using SimplifySelectInst on select
> instructions too. However, I found one regression test PR16651.2
> would fail after this potential modification. We would transform
> 
> ```
> define void @PR16651.2() {
> ; This test case caused a crash due to failing to promote given a
> select that
> ; can't be speculated. It shouldn't be promoted, but we missed that
> fact when
> ; analyzing whether we could form a vector promotion because that
> code didn't
> ; bail on select instructions.
> ;
> ; CHECK-LABEL: @PR16651.2(
> ; CHECK: alloca <2 x float>
> ; CHECK: ret void
> 
> entry:
>   %tv1 = alloca { <2 x float>, <2 x float> }, align 8
>   %0 = getelementptr { <2 x float>, <2 x float> }* %tv1, i64 0, i32 1
>   store <2 x float> undef, <2 x float>* %0, align 8
>   %1 = getelementptr inbounds { <2 x float>, <2 x float> }* %tv1, i64
>   0, i32 1, i64 0
>   %cond105.in.i.i = select i1 undef, float* null, float* %1
>   %cond105.i.i = load float* %cond105.in.i.i, align 8
>   ret void
> }
> ```
> to
> ```
> define void @PR16651.2() {
> entry:
>   %cond105.in.i.i = select i1 undef, float* null, float* undef
>   %cond105.i.i = load float* %cond105.in.i.i, align 8
>   ret void
> }
> ```
> 
> Is this transformation on PR16651.2 valid? 

It looks like this transformation is valid only if loading from an undef address always produces an undef value (and never traps). In the original code, loading from %1 always produced an undef value (because undef was explicitly stored into that location, but would have been undef anyway because it is an otherwise-fresh alloca), but did not trap. So if we always replaced undef addresses with some equivalently-sized constant-pool load (or something like that), then this might work. I don't know that we do that, however.

 -Hal

> If no, can somebody help
> me understand why it isn't?
> 
> Thanks,
> Jingyue
> 
> http://reviews.llvm.org/D4659
> 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

http://reviews.llvm.org/D4659