Re: [trunk]: patch to properly build the conflict graph

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

Kenneth Zadeck <zadeck@naturalbridge.com> writes:
> Seongbae Park (???, ???) wrote:
>> On 9/30/07, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
>>   
>>> This is an updated patch based on several comments that were made by Richard Sandiford.
>>>
>>> There are two significant changes as well as several comments that were added or fixed.
>>>
>>> 1) Several bugs were found in ra-conflict.c:set_renumbers_live that had to do with the way that offsets were computed.  These are now fixed
>>>
>>> 2) At richard's request the code in check_insn_for_earlyclobber and set_conflicts_for_earlyclobber has been completely replaced with a new function set_conflicts_for_earlyclobber that works completely differently.
>>>
>>> The old code originally came from global.c:make_accurate_live_analysis and was modified once to go into the df_problems.c for the UREC problem.  Richard thought this code had exceeded the crufty limit as well as it was overly conservative.  The new code considers each alternative of the insn separately rather than merging all of the alternatives and analyzing that.  In this way fewer interferences will be added if the earlyclobbers only appear on some alternatives and the sets of registers that the inputs can be allocated to vary between alternatives.
>>>
>>> I do not know how much this makes a difference in practice.  I assume that it is highly platform dependent.
>>>
>>> I have tested this i86-{64,32} as well as the ia-64 and ppc-32.  Peter is checking this on the ppc-64 and I have asked richard to check this on the mips.
>>>
>>> Kenny
>>>     
>>
>> ra-conflict.c:273-287 is puzzling to me.
>> Can you explain (and add comments on) why inner "if" is necessary
>> and what it does (especially in regard to recog_data.operand[use+1]) ?
>>
>> Seongbae
>>   
> When i asked richard about this last night, this is what he said.
>
>> > I do not off the top of my head see what this last optimization is
>> > supposed to accomplish.
>> > It seems that the conflict in the second call to
>> > add_conflicts_for_early_clobber would get added in the next round thru
>> > the "for (use=" loop.
>> >
>> > However, i will start testing it.  I had almost finished testing the
>> > other case (with the dreg/ureg typo in it) and it looks clean, but i
>> > will fire everything up again.  What's time to a pig?
>
>> 
>> Heh.  Sorry  ;) 
>>
>> The reason we need to consider commutative operands is that the
>> register classes for USE and USE + 1 may not be the same.
>> 
>> Richard
>
> Perhaps he can send a proper comment to me.  I still do not see it myself, since this would only add more interferences, not refine them further.

Right, that's the idea.  Reload may end up swapping commutative operands,
so you have to take both orderings into account.  The constraints for the
two operands can be completely different.  (Indeed, if the constraints
for the two operands are the same for all alternatives, there's no point
marking them as commutative.)

Richard