This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Optimize ASAN_CHECK checks
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Dodji Seketeli <dodji at redhat dot com>, Yury Gribov <y dot gribov at samsung dot com>, Jan Hubicka <hubicka at ucw dot cz>, Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 14 Nov 2014 13:16:36 +0100 (CET)
- Subject: Re: [PATCH] Optimize ASAN_CHECK checks
- Authentication-results: sourceware.org; auth=none
- References: <20141105102918 dot GX20462 at redhat dot com> <20141105105020 dot GC5026 at tucnak dot redhat dot com> <20141111174234 dot GK5026 at tucnak dot redhat dot com> <546325E7 dot 6080005 at samsung dot com> <20141112103416 dot GR5026 at tucnak dot redhat dot com> <54634007 dot 1050802 at samsung dot com> <20141112223850 dot GW5026 at tucnak dot redhat dot com> <87h9y2owge dot fsf at redhat dot com> <20141114115547 dot GO5026 at tucnak dot redhat dot com> <87oasaf0kj dot fsf at redhat dot com> <20141114121105 dot GP5026 at tucnak dot redhat dot com>
On Fri, 14 Nov 2014, Jakub Jelinek wrote:
> On Fri, Nov 14, 2014 at 01:06:52PM +0100, Dodji Seketeli wrote:
> > Jakub Jelinek <jakub@redhat.com> writes:
> >
> > >> I am not sure, but I am wondering if we shouldn't save the previous uid
> > >> of 'stmt' here before setting it, and then restore it before getting out
> > >> of this function.
> > >
> > > No, gimple uids are AFAIK undefined at the start of passes, passes that use
> > > them are supposed to initialize them before use (new statements created
> > > during the pass will get 0 there by default), and don't have to clean them
> > > up anyway at the end of pass.
> >
> > Yeah, this is what I figured by grepping other passes, but I wasn't sure
> > :-)
> >
> > Maybe I should follow up with a doc patch for the (otherwise very terse)
> > comment of gimple_set_uid and gimple_uid accessors.
>
> That would be indeed nice (similarly for other stuff that we expect to be
> undefined on pass boundaries, or expect to be in certain state at pass
> boundaries; in the former case set before uses, and don't care about what
> state we leave it in, in the latter case can assume some state first (say 0)
> and have to put it back into the same state). There are various visited
> flags and the like, Richard, any ideas what other things might be nice to
> document?
aux pointers on CFG structures which I believe have to be cleared
after each pass that uses them (maybe already documented).
Nothing else off the top of my head.
Richard.