Re: RFA: patch to solve PR37535

[Richard Sandiford <rdsandiford at googlemail dot com>]

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.

The answer seems to be: it depends.  We should conservatively treat it
as an earlyclobber for register-allocation purposes, but we shouldn't be
surprised if (as here) insns actually force a use of the clobbered
value.

I'm certainly not claiming this is a good design ;)

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

OK, thanks.  I just wish the fix in this case was more elegant...

Richard