http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 7 May 2014, glisse at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61034 > > --- Comment #11 from Marc Glisse <glisse at gcc dot gnu.org> --- > The committed patch doesn't seem to optimize as well as the hack. fre2 (- is > the hack and + is the new trunk, unless I confused my directories): > > - _8 = _98; > + _8 = MEM[(const struct I &)b_9(D)].o; > > - _224 = _201; > + _224 = _18->count; > > etc > > I assume that's because call_may_clobber_ref_p_1 sometimes says that free > clobbers its argument while the hack was assuming it never does. "free" is > strange, somehow here we would want call_may_clobber_ref_p_1 to return false > (we can't be reading after a free, so we must have taken another path, this > free didn't run and didn't clobber anything) even when stmt_kills_ref_p_1 > would > return true, but that would confuse other parts of gcc. Yeah, I know. call_may_clobber_ref_p_1 has to guard against sinking a load across it as well. I'm working on improving value-numbering in other ways at the moment, we can come back and special-case free and va_end builtins later in SCCVN.
