RFA: patch to solve PR37535

[H.J. Lu]

On Tue, Sep 23, 2008 at 12:32 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> H.J. Lu wrote:
>>
>> On Mon, Sep 22, 2008 at 3:25 PM, Vladimir Makarov <vmakarov@redhat.com>
>> wrote:
>>
>>>
>>> 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.
>>>
>>>
>>>
>>
>> Hi Vladimir,
>>
>> It doesn't work on Linux/ia32. I applied your patch to ira-merge
>> branch. On Linux/ia32, I got
>>
>> make[5]: Leaving directory `/export/build/gnu/gcc-ira/build-i686-linux'
>> Comparing stages 2 and 3
>> warning: ./cc1-checksum.o differs
>> warning: ./cc1plus-checksum.o differs
>> warning: ./cc1obj-checksum.o differs
>> Bootstrap comparison failure!
>> ./tree-vect-transform.o differs
>> make[4]: *** [compare] Error 1
>> make[4]: Leaving directory `/export/build/gnu/gcc-ira/build-i686-linux'
>> make[3]: *** [stage3-bubble] Error 2
>> make[3]: Leaving directory `/export/build/gnu/gcc-ira/build-i686-linux'
>> make[2]: *** [bootstrap] Error 2
>>
>>
>>
>
> Sorry, H.J.  I tried to reproduce the bootstrap failure on i686 but failed
> (I've tried this on the branch and the trunk).  I don't think the problem is
> in the patch.  Although this failure is really annoying.   It looks like my
> patch removing doubles did not help.  Could you give me more info about your
> machine (OS, bash or csh, config options, gcc version used on stage1). May
> be I'll be more lucky with this info to reproduce the bug.
>
>

I am using gcc-4.1.2-42.el5 on RHEL 5.2 client. I used

--enable-clocale=gnu --with-system-zlib --enable-checking=assert
--with-demangler-in-ld  --enable-shared --enable-threads=posix
--enable-haifa --prefix=/usr/gcc-4.4-ira
--with-local-prefix=/usr/local

--enable-checking=assert may make a difference.


-- 
H.J.