prevent (pre_inc ...) from satisfying "movhi" RTL template constraints

[Maxim Blinov <maxim dot a dot blinov at gmail dot com>]

Consider the following templates:

> (define_insn "movhi"
>    [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r,r,m")
>        (match_operand:HI 1 "general_operand" "i,r,m,r"))]
>    ""
>    {
>          return \"move %1, %0\";
>    }
> )
>
> (define_insn "pushhi_16"
>  [(set (mem:HI (pre_inc:HI (reg:HI SP_REG)))
>        (match_operand:HI 0 "general_operand" "rni"))]
>  ""
>  "push %0"
> )

And the following translation unit (if at all relevant):

> volatile int* const e = 0x5;
>
> void _entry() {
>     *e = 6
> }

My question concerns the code generator behavior when confronted by
the following final RTL code; the following snippet is from the prologue,
where the `a' register is saved onto the stack:

...
(insn 12 4 13 (set (mem/c:HI (pre_inc:HI (reg/f:HI 4 sp)) [2  S2 A8])
        (reg:HI 0 a)) test.c:3 1 {movhi}
     (expr_list:REG_DEAD (reg:HI 0 a)
        (nil)))
(note 13 12 3 NOTE_INSN_PROLOGUE_END)
...

>From this, the following (incorrect) code is generated:
>    "move %a, (%sp)"

It is incorrect, as on my machine the %sp register is only incremented
with a push or pop instruction. Thus, the correct code should be:
>    "push %a"

My question is, why does the compiler match the above RTL code to
my "movhi" template? I have not specified an auto {pre,post}
inc/decremented ("<" or ">") operand constraint anywhere in the
"movhi" template; thus, surely the template match should fail, if the
RTL that is attempted to be matched contains such a *cremented
expression?

I currently solve this problem by simply defining the "push"/"pop" RTL
templates above that of the "movhi", so that they get considered first,
however I would much prefer a solid solution that does not depend on
the position of code in a file.