This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: PA PIC symbolic memory fix PART 2
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Subject: Re: PATCH: PA PIC symbolic memory fix PART 2
- From: Jeffrey A Law <law at redhat dot com>
- Date: Tue, 27 Feb 2001 18:37:47 -0700
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at redhat dot com
In message <200102211758.MAA29559@hiauly1.hia.nrc.ca>you write:
> > Actually, it can easily cut down the number of registers.
> > Instead of extending the lifetime of the destination of the HIGH, you
> > simply resynthesize the HIGH when you need it. It's just an addil
> > instruction, which is way cheap.
> Hmm. This suggests that the the DLT load insn should again be a separate
> insn. Then, when a spill occurs for a source MEM equivalent pseudo, the
> destination register could be used as a scratch register to resynthesize
> the HIGH part. However, we then have to ensure that reload does generate
> a spill when it encounters a PIC DLT reference and resolve the insn
> recognition issues.
I've been pondering the rematerialization of PIC references for the last
few days. And I'm not so convinced anymore that it's worth the effort.
Let's assume the destination pseudo of a load from the DLT doesn't get a
If we don't re-materialize the value when we spill the pseudo to
the stack. That means a store (to initialize the stack slot) and a load
from the stack at each usage site. And we need an ALU op for the
high part. N loads, 1 ALU, 1 store.
If we do rematerialize, then we don't have a store, but we do have
an ALU insn plus a load from the DLT. N loads, N ALUs, 0 stores.
We might be able to save the ALU insn in some cases, but even if we always
are able to re-use the ALU op we really haven't saved anything except a
single store and we've extended the lifetime of a register pretty badly.
So I'm thinking that rematerialization in this case really isn't worth
> This suggests another idea. Instead of breaking the load insn for
> a long pic_ref into two parts, possibly this could be represented in the
> rtl as a single insn. For example,
I'm planning to play a little with our PIC representation tonight. As I
outlined in a previous message, the reasons for having separate insns
are mostly historical and don't provide any real benefit on the PA.