Re: [rfc] multi-word subreg lowering pass

[Björn Haase <bjoern dot m dot haase at web dot de>]

Ian Lance Taylor wrote on Samstag, 3. Juni 2006 06:27 :
> Yes, that case, the case in which the registers can be fully
> decomposed, works OK.  The case that doesn't work OK is when one
> register can be decomposed but the other can not be.  Then you get
>
>   p20:SI <-- subreg:SI p10:DI 0
>   p21:SI <-- subreg:SI p10:DI 4
>
> Let's assume that p10 dies in the second instruction.  Then we want to
> allocate p20/p21 to overlap with p10.  But unfortunately the first
> instruction causes a conflict between p20 and p10, since p10 is still
> live after the first instruction, so the register allocator can't do
> that.
>
> In fact I have now implemented this case.  I've introduced a
> computation of REG_SUBREG_DEAD, though only within a basic block.
> Then the first instruction above will get a REG_SUBREG_DEAD note for
> subreg:SI p10:DI 0 on the first insn above.  I've modified global.c to
> see that and to not introduce a conflict between p20 and p10, and
> p20/p21 and p10 now get allocated to the same register pair in my test
> case.
>
> I now need to do more timing tests to see if I get improvements on
> real code.
>
> Ian
Hi Ian,

I am now observing the same problem concerning the register 
allocation :-( with my experimental version of the avr port. I.e. there is a 
problem if the subreg could not be completely lowered.
After studying the issue a bit, I'd like to suggest an alternative to adding a 
new pass in order to overcome the conflict detection difficulty:

IIUC, everything would be fine, if after splitting all of the lowered 
instruction patterns are embraced by a libcall sequence of the type

(clobber (destination))
... sequence of splitted insn
(set (destination) (destination))

where the individual splitted insn patterns carry the "REG_NO_CONFLICT" note 
for the input registers. If complete lowering succeeds, anything is fine 
anyway. If not, the register allocator would have the necessary hint.

The present problem is, that the splitters right now are not able to add the 
desired notes.

After looking at genemit.c, I made the observation, that without too much of a 
change, one could extend the splitter's capability to generate a complete 
libcall sequence, if desired.

I.e. for all of the individual splitter functions generated by genemit.c one 
would add a line 
"bool generate_libcall_sequence = FALSE;"
defining a new local variable. The default value could be altered by the 
preparation statements of the splitting pattern to TRUE.

If generation of a libcall sequence is desired, the splitted sequence pattern 
would be required include a leading
(clobber (dest)) and a trailing (set (dest) (dest)).

If generate_libcall_sequence evaluates to TRUE the first and last generated 
insn of the sequence would get a REG_RETVAL and a REG_LIBCALL note 
respectively.
For all of the other insn of the generated pattern a REG_NO_CONFLICT note with 
all of the input pseudos would be added. (One would be using a short helper 
function for this purpose).

Comments would be welcome :-)!

Bjoern.