Re: RFA: patch to solve PR37535

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.


-- 
H.J.