This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: PA PIC symbolic memory fix PART 2

  In message <>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
hard reg.

  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
the headache.

  > 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]