This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, Jeff Law <law at redhat dot com>, Richard Earnshaw <rearnsha at arm dot com>, Bin Cheng <bin dot cheng at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 3 Sep 2014 08:20:57 -0500
- Subject: Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass
- Authentication-results: sourceware.org; auth=none
- References: <20140901175036 dot GA6643 at gate dot crashing dot org> <201409021210 dot s82CAWsP031216 at d06av02 dot portsmouth dot uk dot ibm dot com> <20140902134050 dot GA13829 at gate dot crashing dot org> <CAHFci2-bWoj66MpDmX55xbH7w8B0ajMQPiV1Aun-f5vB_XKm+w at mail dot gmail dot com>
On Wed, Sep 03, 2014 at 10:34:39AM +0800, Bin.Cheng wrote:
> >> Now I guess this check could be relaxed if somewhere else in combine we'd
> >> recognize the substitution into a clobber and simply omit it in that case.
> >
> > Yeah.
> >
> > In the testcase, combine tries combining 76,77 (77 is that clobbering
> > insn) and refuses it; then it tries 32,76,77 and refuses it; and then
> > it tries 32,76,77,43 and allows it (it doesn't do this check at all,
> > 77 is not i3, combine omits the clobber completely). Which is inconsistent.
>
> I guess it makes sense because this way it doesn't introduce any
> invalid instructions. But yes, how combine handles the clobber in
> this way may help combine the three instructions?
Combine could just throw away all clobbers on i3 and add them back if
wanted by the combined insn. I think it does things the way it does so
that it creates slightly less garbage RTL and/or it is a little less work.
But it does disallow this case; easily fixed, have patch, will post in a
minute.
That will hide your problem, but not really fix it I think. Maybe we
need to disallow all combos that set the same register twice in four-insn
combinations. Or at least when that register does not die. Why is this
combination tried anyway? r84 (as set in 77, used in 43) does not die,
so this is just doing a very expensive very limited form of un-cse?
Segher