Re: [PATCH] resubmitted for review to fix modulo scheduling. COMMITTED

[Bernd Schmidt <bernds_cb1 at t-online dot de>]

Kenneth Zadeck wrote:
> I could be wrong here but I thought that this form of subregs were put
> into gcc so that it was obvious to the compiler which bits were being
> preserved and which bits were being destroyed.   This is a message that
> may not have made it to the masses who support the ports and have hacked
> on much of the back end, but subregs seem to me a perfectly reasonable
> way to represent partial word operations until very late in the code
> generation process.

I don't know why they were put in.  There are a lot of things in gcc 
that probably seemed like a good idea at the time.  I do not think this 
should matter; I can only repeat myself: as far as RU is concerned, this 
is an irrelevant implementation detail.

> What danny and I have done is build the transfer
> functions so that it conveys this information to the client of dataflow
> so that those clients can take advantage of this.

Let's take an example, from the perspective of a hypothetical client.

 1 (set x 40000)
 2 (set (strict_low x) 23)
 3 (use x)

So, let's assume the client wants the set of defs that can reach any 
given use.  If the df problem ignores partial sets, any user of the the 
produced data could think that x can have two possible values at the 
point of use, one of them the value 40000.  This seems quite plainly 
bogus to me.

If we don't ignore partial sets, we get one possible value, which is 
produced by inserting 23 into the low part of the value of X at 2.  That 
use also has one possible definition which is 40000.  So, by looking at 
the RTL _in the client_, we could work out the correct value.  If we 
produce bogus information in the RU pass, we can't do this.

df does not track individual parts (bits, bytes, whatever) of registers. 
 The basic unit it operates on is one register, and even a partial 
store affects that as a whole.  If you wanted to track single bytes in a 
manner similar to the way the separate words of a multi-word value are 
tracked, then this would make more sense, you could then leave 3/4 of 
the reg unaffected if you have a strict_low_part byte store.  Since df 
isn't doing that, it serves no purpose to treat partial stores this way, 
since the produced information is not in a format that can be sensibly used.


Bernd