Re: PATCH: PA PIC symbolic memory fix PART 2

[Jeffrey A Law <law at redhat dot com>]

  In message <200102211758.MAA29559@hiauly1.hia.nrc.ca>you write:
  > 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.
Maybe -- you still also have to get %r1 as a temporary as the addil
instruction always has %r1 as its destinatin.

  > 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'd been thinking about this myself.  They're separate mostly for historical
reasons.  For non-PIC code it is very profitable to split up the HIGH and
LO_SUM expressions -- when the PIC support was added we followed the same
basic model for representing addresses (separate HIGH and LO_SUM expressions).

The reasons it's profitable to split up HIGH and LO_SUM for non-PIC code are:

	a. We can use a single HIGH with several different LO_SUM expressions.

	b. We can combine the LO_SUM with the actual memory reference and
	the HIGH part can be hoisted out of loops.  This eliminates one
	of the two insns to compute the address of a symbol and moves all
	the overhead out of loops.

	c. Since they're two instructions, we can get better schedules by
	exposing them as separate insns to the instruction scheduler.


"a" & "b" do not apply for PIC code.  We can still do "c" with a post-reload
splitter.  So the benefit of splitting up those insns early for PIC is
minimal.



  > (set (reg:) (mem: (low_sum: (plus: (pic_offset_table_rtx) (high: (symbol))
  > 			    (unspec: [(symbol)] 0))))
Actually, we'd drop the HIGH and LO_SUM completely from this expression.  I'd
probably just represent it as

(set (reg) (unspec (symbol))

Possibly removing the unspec too.  

The only reason for exposing the MEM was for scheduling purposes, and we
can still tag the insn as a memory load for the scheduler even if we don't
show the MEM in the RTL.

  > I don't know enough about splitters but possibly this could be split
  > after reload for further optimisation.  The HP linker can also eliminate
  > unnecessary addil's.
Only when not generating PIC code unless it's changed recently.  Also note
that this kind of linker optimization has two bad effects:

	a. Screws debugging in more ways than you can shake a stick at.

	b. Screws up schedules.  This can be particularly important on the
	PA8000 and newer machines.


jeff