Re: RFA: highpart life analysis

[Joern Rennecke <joern dot rennecke at superh dot com>]

> 
> Hi Joern,
> 
> > 	* basic-block.h (struct basic_block_def): New members
> > 	global_high_live_at_start and global_high_live_at_end.
> > 	(PROP_HIGH_LIFE, PROP_KILL_DEAD_EXTENDS): New defines.
> > :
> 
> What does your pass do?  I am guessing that unnecessary zero/sign

I've already outlined it here:

http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02029.html

> extensions and such are deleted.  For example, consider:
> 
> unsigned short s0, s1, s2;
> 
> void
> foo (void)
> {
>   unsigned long c = s0;
>   s1 = c;
>   s2 = c;
> }
> 
> In this piece of code, the zero extension from s0 to c is unnecessary,
> but ASAIK, no pass removes that.  Is this more or less correct?  Or am

ASAIK?  Do you mean AFAIK?

> I completely lost?

If your highpart attribute uses the bits that do not belong to short as
a highpart, then the my patch will do that, yes.

For SHmedia, I have made it use anything above bit 31 as a highpart,
so it'll do this optimization with long long va. unsigned.
It probably makes sense to make the attribute use bits above 15 as
a highpart for SH1..SH4, which should give you the optimization for
your original testcase.

> If that's the case, I like the idea, but I am afraid that having the
> port explicitly specify attributes is a pain.  In a lot of cases, like
> zero/sign exntesions or AND with certain constants, we can tell what
> the attribute should be by looking at patterns.  (The down side is
> that without the attribute, we would be adding more code doing rtl
> pattern matching, which is often tough to read.)

If I wanted to track arbitrary highparts, I'd need more bits to track
which parts of the register are live.  With the attribute, the port
can determine which kind of highpart is important enough to have a full
extra set of liveness information.  Moreover, there are a number of
instructions patterns for SHmedia where the rtl does not tell the
full story, in particular all unspecs and all SImode operations.

> Doing this in tree-ssa is probably another idea, but I don't know how
> challenging that would be.

It's also a separate issue, since data flow analyis makes sense both
at early and at late optimization stages.


> > +   including highpart lifeness calculations.  */
>                          ~~~~~~~~
>                          liveness (throughout the patch.)

grep says that are five places that need to be fixed, is that right?