Re: RFA: patch to solve PR37535

[Vladimir Makarov <vmakarov at redhat dot com>]

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.
> but I don't think that makes any difference for these pa and s390 patterns,
> where the input operands are hard regs that are either hard-coded into
> the .md file, or that have empty constraints.
>
> I notice you said:
>
>     Unfortunately using DF for building conflicts became more
>     complicated that it was before based on REG notes.  So it will take
>     some time.
>
> I'm sorry to hear that you're so unhappy with that change.  I'm happy
> to back it out if you'd prefer.  (Really.)
>
>   
Richard, that is not your fault :)  If you look at ra-conflicts.c which 
is used by the old RA, your code using DF is much more clear.
As H.J. wrote it fixes some EH failures.  I don't remember details but I 
remember the code based on REG notes worked wrong because DF generates 
wrong live info at the start of BB for some hard registers.  It is not a 
problem for the old RA because live at BB start is not used by the old 
RA.  Because I don't want touch DF-infrastructure to fix it and many 
people believes that we should rid of reg notes (the last place where it 
is used is reload), I prefer your code for building conflicts based on 
DF-infrastructure.  We just need to fix it.