Fix PR 49014

Vladimir Makarov vmakarov@redhat.com
Thu Jul 7 16:28:00 GMT 2011


On 07/01/2011 10:50 AM, Andrey Belevantsev wrote:
> On 26.05.2011 17:32, Andrey Belevantsev wrote:
>> On 25.05.2011 19:31, Bernd Schmidt wrote:
>>> On 05/25/2011 03:29 PM, Andrey Belevantsev wrote:
>>>> I think the hook is a better idea than the attribute because nobody 
>>>> will
>>>> care to mark all offending insns with an attribute.
>>>
>>> I don't know. IIRC when I looked at sh or whatever the broken port was,
>>> it was only two insns - there would still be some value in being 
>>> able to
>>> assert that all other insns have a reservation.
>> OK, I will take a look on x86-64 and will get back with more 
>> information.
>>
>> Andrey
> So, I have made an attempt to bootstrap on x86-64 with the extra 
> assert in selective scheduling that assumes the DFA state always 
> changes when issuing a recog_memoized >=0 insn (patch attached).  
> Indeed, there are just a few general insns that don't have proper 
> reservations.  However, it was a surprise to me to see that almost any 
> insn with SSE registers fails this assert and thus does not get 
> properly scheduled.
>
> Overall, the work on fixing those seems doable, it took just a day to 
> get the compiler bootstrapped (of course, the testsuite may bring much 
> more issues).  So, if there is an agreement on marking a few offending 
> insns with the new attribute, we can proceed with the help of somebody 
> from the x86 land on fixing those and researching for other targets.
>
The changes in sel-sched.c is ok for me.  i386.md changes look ok for me 
too but you should ask a x86 maintainer to get an approval for the change.

I think you should describe the attribute in the documentation because 
it is common for all targets.

I can not approve common.opt changes because it makes selective 
scheduler is default for the 2nd insn scheduling for all targets.  Such 
change should be justified by thorough testing and benchmarking 
(compilation speed, code size, performance improvements) on several 
platforms (at least on major ones).



More information about the Gcc-patches mailing list