RE: Register Rematerialization In New Register Allocator

["Mukta Punjani, Noida" <muktap at noida dot hcltech dot com>]

>>    o df.h - struct ref(corresponding to each def) to be 
>>modified to hold the
>> remat insn sequence (in terms of the insn uids) for the def 
>>making up the
>> insn chain.
>>
>Hmm, so you not just want to remember the actual expression, but really
>the whole construction sequence, which possibly consists of more than
>one insn, yes?  Why?  IOW why is the expression itself not enough?  I
>would guess, that if for instance the 'pattern' would contain something
>like:
>  (plus:SI (plus:SI (mult:SI (reg:SI x) (reg:SI y)) (reg:SI 
>z)) (const 4))
>the necessary insn sequence to actually calculate this 
>expression can be
>generated on the fly.

Your idea seems to be good.
However, consider the case of the following pseudo code:

	insn_uid			isns
remat_sequence(insn uid chain)
        14			r148 = (any remat source????)   14
        18              r149 = r148 + 12                14,18
        23              r150 = r149 + 32                14,18,23
        30              r151 = r149 + r150              14,18,(14,18 from
r150's remat_sequence checked for
                                                               redundancy
and removed),23,30

I feel that such a sequence should not occur on most of the architectures
for address arithmetic computation (Not sure of the other computations).
However, if such a case can exist, then the pattern cannot be possibly
created without avoiding the redundancy of 14,18 as shown above. But in case
the insn uids are used to construct the remat_sequence, then this problem
can be taken care of.

Also possibly, the compile time overhead for packing such a pattern and then
unpacking in case it needs to be remat would be there.

Is there a viable solution to this alternative.

Thanks for the comments on this matter.

Best Regards,
Mukta