https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #12)
> As for the .DEFERRED_INIT not being DSEd when it isn't used, cvise reduced
> testcase is e.g.
>
> int a;
> int foo (void);
> int bar (void);
>
> void
> baz (void)
> {
> int *b[6];
> if (foo ())
> a |= bar ();
> }
>
> while with a |= 1; instead dse1 removes it. Richi, any thoughts on that?
> Of course, the real bug is on the x86 backend side.
The reason why we do not DSE the .DEFERRED_INIT is because of the VDEF->VUSE
walking limitation in dse_classify_store, in particular we fail to follow
the chain of VDEFs in BB3 when the uses are the one in the merge PHI in BB4
and the first call in BB3.
Fortunately for single-arg PHIs I've added proper handling for this and
this can be extended to cover this case. I'm testing a patch, but not sure
if it's appropriate at this stage.
