Re: Why can't CSE recognize const_int's in HIGH LO_SUM pair?

[law at redhat dot com]

  In message <200109110311.f8B3BrYm014073@hiauly1.hia.nrc.ca>you write:
  > >   > 	(set (reg T) (const_int 0x10000))
  > >   > 	(set (reg A) (plus (reg T) (const_int 1)))
  > >   > 	(set (reg B) (plus (reg T) (const_int 2)))
  > >   > 
  > >   > Now consider A and B loaded on two different paths.  Code motion can
  > >   > then pull T up into the dominator.
  > > But recall that we don't do this right now on the PA due to implementatio
  > n
  > > issues.
  > 
  > I was planning on trying to implement this later this week.  At the moment,
  > I am pounding nails helping with a new house for my sister.
Sounds like fun :-)   I've spent most of my spare time over the last few
months renovating our old house.  Richard -- you probably wouldn't recognize
the old house anymore :-)

Anyway....

  > It is clear that either the above, or just
  > 
  > (set (reg A) (const_int)) 
  > 
  > is better than the current high/lo_sum.  However, I don't see a consensis
  > from the discussion as to which approach is better.
I'm not sure either.

(set (reg a) (const_int ))	/* High part */
(set (reg b) (plus (reg a) (const_int))  /* Low part */

Has the advantage of being able to share the high part across multiple
constant loads, much like we do for symbolic references with offsets.

The only downside I see offhand is CSE knows high/lo_sum is somewhat special,
but I would expect it to be able to grok the above sequence just as well to
determine the constant value for (reg b).

jeff