This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Look through clobber stmts in uninit (PR tree-optimization/79345)


On Mon, 20 Feb 2017, Marc Glisse wrote:

> On Mon, 20 Feb 2017, Jakub Jelinek wrote:
> 
> > As mentioned by Jason in the PR, we've regressed on the following testcase
> > since we started emitting CLOBBERs at the start of ctors (and we warn as
> > before with -fno-lifetime-dse -Wuninitialized).
> > With -fno-lifetime-dse, the vuse on the b.x read stmt is default def
> > and thus we warn, but if there are clobbers before that, that is not the
> > case and we don't warn.  The patch is quick hack to bypass the initial
> > clobbers as long as there aren't really many.  If we wanted to handle
> > all initial clobbers, I bet the first time we run into this we could
> > recursively walk vop uses from the default def and build say a bitmap
> > of vop SSA_NAMEs which are vdefs of clobbers that only have clobbers
> > before it as vdef stmts.
> 
>   MEM[(struct  &)&b] ={v} {CLOBBER};
>   _4 = b.x;
>   if (_4 != 0)
> 
> It would be nice (at some point in a distant future) to turn that into
> 
>   MEM[(struct  &)&b] ={v} {CLOBBER};
>   if (_4(D) != 0)
> 
> i.e. replace reads from clobbered memory with a default def (with a gimple_nop
> defining statement).
> 
> IIRC I tried to do it in FRE once, but failed.

Yeah, FRE isn't too happy about VN_TOP in the lattice (which is what
you'd use here).  I also have/had patches trying to make it (more) happy
about VN_TOP but it still broke stuff like for example tail-merging...

Need to dissect PRE from tail-merging again, and also possibly PRE
from value-numbering (run eliminate() before doing PRE).

Richard.

> > Now, the comment says:
> >          /* For memory the only cheap thing we can do is see if we
> >             have a use of the default def of the virtual operand.
> >             ???  Not so cheap would be to use the alias oracle via
> >             walk_aliased_vdefs, if we don't find any aliasing vdef
> >             warn as is-used-uninitialized, if we don't find an aliasing
> >             vdef that kills our use (stmt_kills_ref_p), warn as
> >             may-be-used-uninitialized.  But this walk is quadratic and
> >             so must be limited which means we would miss warning
> >             opportunities.  */
> > I wonder if it isn't useful to walk even limited number of vdefs this way
> 
> Seems worth a try for gcc8, there are several PRs it could help with.
> 
> > anyway (likely GCC8 material though), e.g. if we run into a clobber that
> > must (rather than just may) portion of the read ref (and of course when
> > seeing non-clobber stmt that could alias with the ref give up before that),
> > we could warn even if we are very far from the start of the function.
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]