Re: PA move_operand

[law at redhat dot com]

  In message <Pine.LNX.4.21.0103221410310.11752-100000@front.linuxcare.com.au>y
ou write:
  > Hi Jeff, 
  >   This change has a hole in it. :-(
  > 
  > Mon Feb 19 20:24:50 2001  Jeffrey A Law  (law@cygnus.com)
  > 
  >         * pa.c (move_operand): Accept code to load the address of a
  >         symbol out of the DLT as a valid move operand.
  >         (print_operand, case 'A'): New to handle generating a DLT
  >         reference for a LO_SUM expression.
  >         * pa.h (EXTRA_CONSTRAINT): Handle 'A' for DLT LO_SUM references.
  >         * pa.md (movsi, movdi patterns): Allow DLT LO_SUM references.
  > 
  > The problem being that there is nothing to prohibit global_alloc doing
  > things like the following:
  > 
  > (insn 313 311 315 (set (reg/v/f:SI 50 %fr13 [186])
  >         (mem/u:SI (lo_sum:SI (reg:SI 1 %r1 [187])
  >                 (unspec:SI[ 
  >                         (symbol_ref/v:SI ("*.LC92"))
  >                     ]  0)) 0)) 68 {*pa.md:2088} (insn_list 311 (insn_list 3
  > 11 (nil)))
  >     (expr_list:REG_DEAD (reg:SI 1 %r1 [187])
  >         (nil)))
  > 
  > which leads to an abort in output_operand.  For cpus < PA2.0 we can't do
  > more than a -32..+31 offset anyway, so the above needs to be split into
  > 
  > (set (reg %r1) (lo_sum (reg %r1) (symbol_ref ("*.LC92"))))
  > (set (reg %fr13) (mem (reg %r1)))
  > 
  > How and where this should happen, I'm not too sure.  Which is why I'm
  > asking here instead of spending a day or so that I can ill afford at the
  > moment learning more about gcc.
I'm on the road the bulk of the next two weeks, so it's going to be
hard for me to look at this.

Do you have a testcase?

Something severely hokey must be happening.  First, using an FP reg as
the destination is silly since all we're going to do is turn around and
use that as an address for a later load/store insn.  So I'd peek at the
register preferencing to see if we're doing something stupid there.

Second, reload should have realized the constraints did not match and
reworked things so that they did match.

You might put a breakpoint in reload_cse and see what the insn looks like
immediately after reload, but before any of the post-reload optimizers
run.
jeff