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

[Daniel Berlin <dan at cgsoftware dot com>]

Richard Henderson <rth@redhat.com> writes:

SW> On Mon, Sep 10, 2001 at 11:29:56AM -0600, law@redhat.com wrote:
> > True.  But with the way things are currently implemented I don't think
>> we actually lose anything on the PA by not exposing the subexpressions
>> to gcse.  Instead of commonizing the HIGH and LO_SUM parts with other
>> idential ones elsewhere, we end up commonizing (set (reg) (const_int))
>
> Consider
>
> 	(set (reg A) (const_int 0x10001))
> 	(set (reg B) (const_int 0x10002))

>
> as
>
> 	(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.
And thus, increase register pressure.
Without rematerialization,  or live range splitting, we'd spill twice
as much as we would before here.
But this won't *really* happen, because we'd split it before register
allocation.
And since we CSE the hard regs after register allocation, it might be
gone.
And if that doesn't do it, we could change the current  scheduling
into something like dominator path scheduling could move that
without any copies.
--Dan

>
>
> r~

-- 
"When I have a kid, I want to buy one of those strollers for
twins.  Then put the kid in and run around, looking frantic.
When he gets older, I'd tell him he used to have a brother, but
he didn't obey.
"-Steven Wright