This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why can't CSE recognize const_int's in HIGH LO_SUM pair?
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Subject: Re: Why can't CSE recognize const_int's in HIGH LO_SUM pair?
- From: law at redhat dot com
- Date: Mon, 10 Sep 2001 10:23:01 -0600
- cc: bernds at redhat dot com (Bernd Schmidt), rth at redhat dot com, gcc at gcc dot gnu dot org
- Reply-To: law at redhat dot com
In message <200109081718.f88HIpZ0020468@hiauly1.hia.nrc.ca>you write:
> I am fairly certain that it is true on the PA. In fact, I think more
> generally the form (lo_sum (reg) (rtx)) is always equivalent to (rtx).
> (reg) is always (high (rtx)). If this is not true on all ports, possibly
> a flag bit (unchanging?) could be set in the LO_SUM to indicate this.
Yes, this is true for compile time constants on the PA. It is not true for
symbolic references. We can (and do) take advantage of the overlap in
bits set by HIGH and LO_SUM on the PA for symbolic addresses. This allows
a series of different LO_SUM expressions to share a single HIGH expression.
We could do the same for compile-time constants, but don't.
This is mostly historical -- the PA port is modeled after the SPARC port;
the SPARC used HIGH/LO_SUM for constants, so the PA does the same thing.
We could just as easily emit
(set (reg1) (const_int HHHHHHH)
(set (reg2) (plus (reg1) (const_int LLLLLL)))
Where HHHHH are the high bits and LLLLL are the low bits. This might be
easier for the optimizers to grok.
Or, we could just emit
(set (reg) (const_int XXXXXXXX))
And keep it in that form until a later point in the compilation process.
jeff