-fstrict-aliasing fixes 4/6: do not fiddle with flag_strict_aliasing when expanding debug locations

Jakub Jelinek jakub@redhat.com
Wed Dec 2 09:15:00 GMT 2015


On Wed, Dec 02, 2015 at 10:05:13AM +0100, Richard Biener wrote:
> On Wed, 2 Dec 2015, Jan Hubicka wrote:
> 
> > Hi,
> > this patch removes flag_strict_aliasing kludge in expanding debug locations and
> > instead it introduces explicit parameter DEBUG that makes
> > set_mem_attributes_minus_bitpos to not affect alias sets.  This is sanity
> > checked by comparing number of alias sets before and after at a time we
> > originally overwritten flag_strict_aliasing.
> > 
> > I also added code to prevent memory attributes creation for !optimize and to
> > avoid get_alias_set computation for !flag_strict_aliasing. This slightly
> > optimizes -O0 builds but the results seems to be down in the noise (I would not
> > object to leave it out).
> > 
> > The patch should fix at least one (latent?) bug that call_stmt expansion
> > invoke expand_debug_expr without clearing flag_strict_aliasing.
> > 
> > Bootstrapped/regtested x86_64-linux, also tested with compare-debug, OK?
> 
> First of all, why do debug MEMs need mem-attrs?

For aliasing purposes, like any other MEMs.  var-tracking needs to be able
to find out if some store through say some pointer could alias certain debug
MEM (then we need to flush the corresponding VALUEs), or not (then that
VALUE can be still considered live at that MEM location).

	Jakub



More information about the Gcc-patches mailing list