(In reply to vries from comment #12)
> Created attachment 33220 [details]
> Alternative patch
>
> > But that line is never executed at runtime (well, unless tail
> > merging comes along and makes it the only version present).
>
> Ah, right, we consider a program with dead type-unsafe code valid.
>
> This follow-up patch attempts to fix things less conservatively on trunk.
> Shall I put this through testing or do you see a problem with this approach?
Hum. I don't like guarding optimizations with !flag_strict_aliasing, that is,
-fno-strict-aliasing shouldn't get us more optimization.
Also on trunk I'd like to rip out the use of the SCCVN lattice from
tail-merging as there FRE/PRE value-replace every SSA name which means
we don't need it. The tight entanglement between PRE and tail-merge has
given me more headaches recently.
> Furthermore, I suspect that a similar issue exists for loads, I'll look into
> that.
(In reply to vries from comment #12)
> Created attachment 33220 [details]
> Alternative patch
>
> > But that line is never executed at runtime (well, unless tail
> > merging comes along and makes it the only version present).
>
> Ah, right, we consider a program with dead type-unsafe code valid.
>
> This follow-up patch attempts to fix things less conservatively on trunk.
> Shall I put this through testing or do you see a problem with this approach?
Hum. I don't like guarding optimizations with !flag_strict_ aliasing, that is, aliasing shouldn't get us more optimization.
-fno-strict-
Also on trunk I'd like to rip out the use of the SCCVN lattice from
tail-merging as there FRE/PRE value-replace every SSA name which means
we don't need it. The tight entanglement between PRE and tail-merge has
given me more headaches recently.
> Furthermore, I suspect that a similar issue exists for loads, I'll look into
> that.
I don't think so.