RE: [PATCH] DF_DU_CHAIN | DF_UD_CHAIN flags in new-ra

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

Hi,

Thanks so much for your comments.

I think that there is some gap in communication here. As I have already
discussed, this is again
a brief explanation of how and what I have implemented for remat --

(I) Remat is done for defs being set from never-killed/constant sources(eg
Frame Pointer FP),
    such as 
	r152 <- FP + 32 		<-- Def for r152 is remat

	...
	r162 <- r152 + 54       <-- Def for r162 is remat provided only 1
def
					    of r152 flows at this point.

    To check that only 1 def for r152 flows into r162, I need the use-def
information.
    The use-def for r162 will make sure that if r162 is set from a
pseudo(r152) which
    in turn is remat, r162 will be remat only if -
	 1. Use-def chain of r152 contains only 1 def at the given point
	 2. And the given def of r152 is remat.

(II) The other point which I think needs to be stressed here is that for
r152 to be backtracked
     till the point it is set from a never-killed/constant source,(I have
backtracked all the  
     pesudos till they are set from a remat source if any), I need the
complete information to be 
     generated before I do the processing for remat.

     Eg. 		r152 <- r14 + 32
	      	r153 <- label_ref(label)  <- const source
		      r157 <- r152 + r153
		
     In this case, to check, if r157 is remat, the use-def chain for r152,
r153 also needs to be
     in place. However, AFAI understand, if I use the existing web based
ud/du chains, this is not
     possible (ud/du chains for a pseudo are destroyed after creation of web
for it).
     
     Use-def chains give me that advantage of the whole information in the
form of DF_REF_CHAIN(use)
     for all the uses.

>Have you a feeling how common this is?  Only remat one def needs checking
>if the use to which remat should be applied really only depends on that
>one def.  I.e. if one reaching def is not rematerializable this use can't
>be remat in this way. 

Remat determination with the help of use-def chains as explained above
(point I)
should explain this. 

>Hence I would think that the vast majority where
>your optimization applied anyway only catches either webs which have only
>one def overall (for which the information in the struct web is exactly
>the ud/du-chain), or to webs where all defs are the same structure wise.

Again, We can remat a lot more cases if I am performing remat not assuming
that all 
defs in web will have the same structure or there will only be 1 def in the
web.

>> 		..................................
>> 		Web:		def1  <-- Remat
>> 				use 11
>> 				use 12
>>
>> 				def2	<-- Not remat
>> 				use21
>> 				use22
>
>For this to be one web, there needs to be a jump from the first chunk
>after def2.

You are right.

Use-def tells us about this fact. Hence we already know that 
DF_REF_CHAIN(u11) = DF_REF_CHAIN(u12) = {def1}
DF_REF_CHAIN(u21) = DF_REF_CHAIN(u22) = {def2}

>Well, this is no different with the info from df.*.  It also needs to be
>generated before it can be used ;)

The backtracking pseudo explanation for remat above(point II) applies here.

>> http://gcc.gnu.org/ml/gcc/2003-09/msg00513.html.
>And I asked if there are cases where it actually makes the defs and
>uses arrays smaller than they were, and why this should fix anything.
>I.e. I think it doesn't fix, but somehow hides the real error.

It is actually for the cases where more defs are generated (during
spilling). In this case,
data structures are NOT reallocated to take care of larger array size, which
results in possible
memory violations.

Regards,
Mukta