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) Richard.
