A very odd phenomenon when does -O1

A very odd phenomenon when does -O1

[He Xiao]

Hi, I've been porting gcc 4.2.0 to a new platform. But there is a very
odd problem when turning -O1 option (or higher level).
As my ISA supports only 13-bit immediate filed, the process of
assigning a value to register should be split into two stage.

(define_insn "movsi_high"
   [(set (match_operand:SI 0 "register_operand" "=b")
        (high:SI (match_operand:SI 1 "const_int_operand" "i")))]
   ""
   "lih \t%0,%U1"
   [(set_attr "type" "move")
    (set_attr "slottable" "no")]

(define_insn "movsi_lo_sum"
   [(set (match_operand:SI 0 "register_operand" "=b")
        (lo_sum:SI (match_operand:SI 1 "register_operand" "b")
                   (match_operand:SI 2 "const_int_operand" "i")))]
   ""
   "or  \t%0,%1,%L2"
   [(set_attr "type" "move")])

The normal pattern to assign values is

(define_insn "arch_movsi"
            [(set (match_operand:SI 0 "nonimmediate_operand" "=b")
                  (match_operand:SI 1 "arch_move_operand"  "i"))]
            ""
            "@
            li \t%0,%1\t\t # movsi: move symbol or label re si"
            [(set_attr "type" "logic")
             (set_attr "slottable" "yes")])

the operad predicate apc_move_operand assert the immediate value is only 13-bit.

(define_predicate "arch_move_operand"
(match_code "mem,reg,subreg,const_int,symbol_ref,label_ref,const")
{
  ... ...
   case const_int:
  return (INTVAL(op) >= -(1 << 13) && INTVAL(op) < (1 << 14));
  ...
}

But when I compile the following statement:
     char* buf[20];
     memcpy (&buf3[18], "ab", 2);

it generates insn before GREG (global register assignment) pass like

(insn 90 43 34 2 (set (reg:SI 58)
       (high:SI (const_int 24930 [0x6162]))) 2 {movsi_high} (nil)
   (expr_list:REG_EQUIV (high:SI (const_int 24930 [0x6162]))
;;0x6162 represents "ab"
       (nil)))

which uses the correct pattern "movsi_high", but after GREG, the insn becomes

(insn 91 40 45 5 (set (reg:SI 27 r27 [orig:54+-2 ] [54])
       (high:SI (const_int 24930 [0x6162]))) 4 {arch_movsi} (nil)
   (nil)

which matches "arch_movsi" pattern, and thus 0x6162 is not qualified
for arch_move_operand, the final output is as follow:

"output_operand: invalid expression as operand"

Is there anybody helping me to figure out how the insn pattern is changing?
--
He Xiao
Shanghai Jiaotong University, 800 Dongchuang Road, Shanghai, China

Re: A very odd phenomenon when does -O1

[Ian Lance Taylor]

He Xiao <xiheasas@gmail.com> writes:

> after GREG, the insn becomes
>
> (insn 91 40 45 5 (set (reg:SI 27 r27 [orig:54+-2 ] [54])
>        (high:SI (const_int 24930 [0x6162]))) 4 {arch_movsi} (nil)
>    (nil)
>
> which matches "arch_movsi" pattern, and thus 0x6162 is not qualified
> for arch_move_operand, the final output is as follow:

Why does this match arch_movsi?  arch_movsi does not have HIGH in the
pattern.  Does your arch_move_operand predicate accept HIGH?  If so,
why?

Note that there are a number of examples of backends with similar
restrictions.  E.g., mips.  They usually do not use HIGH with
CONST_INT; they use HIGH with SYMBOL_REF.  For CONST_INT they split up
the value in the movsi define_expand, and then use predicates to
prevent the real insns from matching anything which the architecture
does not support.

Ian