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

[Jan Hubicka <hubicka at ucw dot cz>]

> On Wed, 2 Dec 2015, Jakub Jelinek wrote:
> 
> > 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).
> 
> Ok, so we then pessimize the alias-set for all of them (when they
> don't have a DECL_RTL already) to use alias-set zero even if we
> wouldn't need to create a new alias set?  (and even if I don't see
> what issues that would cause apart from "messing up the dumps" which
> should be fixed by stripping alias sets from dumps)

Breaking out code into make_decl_rtl_raw is also easy, since set_mem_attributes
is called at very end of make_decl_rtl.

Jakub, in https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00316.html I make get_alias_set
to do the job even in !flas_strict_aliasing because this is needed to make it possible
to mix flag_strict_aliasing and !flag_strict_aliasing functions in one translation
unit.  We do that during LTO.

I wonder how to reproduce the messed up dumps here with that patch and if stripping
the alias sets would be OK? Indeed getting extra alias sets should not cause
codegen differences.

Honza
> 
> Richard.