Re: IA64 HP-UX ILP32 mode patch

[Steve Ellcey <sje at cup dot hp dot com>]

Richard,

I was trying out your extra addp4 instructions in the hopes they would
improve our ILP32 performance on IA64 HP-UX and in particular I added
the following instruction:


(define_insn "*ptr_extend_plus"
  [(set (match_operand:DI 0 "gr_register_operand" "=r")
        (unspec:DI
         [(plus:SI (match_operand:SI 1 "gr_register_operand" "%r")
                   (match_operand:SI 2 "gr_reg_or_14bit_operand" "rI"))]
         24))]
  ""
  "addp4 %0 = %2, %1"
  [(set_attr "itanium_class" "ialu")])


and ran into a problem.  In one program I compiled I got the following code:

        // cycle 11
        ld1 r14 = [r15]
        ld4 r15 = [r17]
        .mmi
        // cycle 12
        st4 [r16] = r18
        ;;
        // cycle 13
        shladd r14 = r14, 2, r0
        ;;
        .mmi
        // cycle 14
        addp4 r14 = r15, r14
        ;;

Now this will fail because r14 is not an address and we use it as the
second argument in the addp4 instruction, thus bits 30 and 31 in r14 are
not what we would expect for a valid 32 bit address and bits 61 and 62
in the resulting 64 bit address are wrong.  If we switched the inputs to
addp4 (r14 and r15) around then it would work because r15 is a valid 32
bit address and all is well.

Without the new instruction r14 and r15 are added together first (thus
setting bits 30 and 31 correctly for a 32 bit address) and then the
addp4 is done.

I don't see anyway of enforcing the idea that at least one of the
register inputs to addp4 must be a "valid" 32 bit pointer before using
it in the ptr_extend_plus instruction and that this input has to be the
second argument in the addp4.  Do you know of any way to do this or do
you think I will have to restrict ptr_extend_plus to only having
integers as its first argument so that the second argument must then be
a register with a valid 32 bit address in it.

Steve Ellcey
sje@cup.hp.com