Re: RFA: patch to solve PR37535

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> H.J. Lu wrote:
> > On Mon, Sep 22, 2008 at 12:20 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> >   
> >> Richard Sandiford wrote:
> >>     
> >>> Vladimir Makarov <vmakarov@redhat.com> writes:
> >>>
> >>>       
> >>>> Richard Sandiford wrote:
> >>>>
> >>>>         
> >>>>> Vladimir Makarov <vmakarov@redhat.com> writes:
> >>>>>
> >>>>>           
> >>>>>> The following patch solves the PR37535.  The analysis of the problem
> >>>>>> can be found on
> >>>>>>
> >>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
> >>>>>>
> >>>>>>             
> >>>>> Thanks for the patch.  But my understanding is that (clobber (reg X))
> >>>>> is an earlyclobber for register-allocation purposes, not an output
> >>>>> clobber.  C.f. the following bit of rtl.texi:
> >>>>>
> >>>>>    When a @code{clobber} expression for a register appears inside a
> >>>>>    @code{parallel} with other side effects, the register allocator
> >>>>>    guarantees that the register is unoccupied both before and after that
> >>>>>    insn.
> >>>>>
> >>>>> It does go on to say:
> >>>>>
> >>>>>    ... However, the reload phase may allocate a register used for one of
> >>>>>    the inputs unless the @samp{&} constraint is specified for the
> >>>>> selected
> >>>>>    alternative (@pxref{Modifiers}).  You can clobber either a specific
> >>>>> hard
> >>>>>    register, a pseudo register, or a @code{scratch} expression; in the
> >>>>>    latter two cases, GCC will allocate a hard register that is available
> >>>>>    there for use as a temporary.
> >>>>>
> >>>>>
> >>>>>           
> >>>> It is hard to say me why we should provide what is written in the first
> >>>> phrase, when it is not guaranteed in reload.  It really has no sense to me.
> >>>>  Probably I miss something here.
> >>>>
> >>>>         
> >>> I suppose it all boils down to: is an _unmatched_ (clobber (reg X))
> >>> an output clobber or an early clobber?  Because it's unmatched, there
> >>> are no constraints to tell us which.
> >>>
> >>>
> >>>       
> >> Ok.  I think my patch is better then.  Because if there is no one early
> >> clobber insn alternative, the patch permits to use clobber hard reg for
> >> input operands in RA (the code would better although to be honest I did not
> >> see the difference out of noise when I tested my patch on SPEC2000 on x86
> >> but the code size is insignificantly smaller).  So instead of your patch, we
> >> could
> >>
> >> 1. use my patch and
> >> 2. modify the documentation to something like that
> >>     
> >
> > Hi Vladimir,
> >
> > Your patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01176.html
> >
> > caused this regression
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37598
> >
> > I don't think it can be applied ASIS. But Richard's
> > patch fixes PR 37535 and doesn't have any regressions
> > on Linux/ia32, Linux/ia64 and Linux/Intel64.
> >
> >
> >   
> I missed that clobbers in asm are actually *early* clobbers.  The new 
> version of the patch removes the regression.  It is mainly an additional 
> code in mark_early_clobbers to deal with clobbers in asm insns.
> 
> The changelog should be the same.
> 
> I'll test the new version of the patch more and submit it for the approval.

I would like to refer you to PR 37608,
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608>.

While PR 37535 was a case with an input hard register and output
clobber, PR 37608 is an early clobber intended to reserve a specific
hard register to save and restore the PIC register across a call.

Richard's change didn't fix PR 37608.  From the discussion, I'm
somewhat hopeful that Vlad's latest proposal will handle this case.
I'm going to give it a try.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)