On 6 January 2011 15:27, Ian Lance Taylor <i...@google.com> wrote:
> Frederic Riss <frederic.r...@gmail.com> writes:
>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:27:1: error:
>> unrecognizable insn:
>> (insn 45 2 46 2
>> ../gcc/testsuite/gcc.c-torture/execute/ieee/930529-1.c:2 (set
>> (subreg:SI (subreg:DF (reg/v:DI 136 [ d ]) 0) 0)
>> (const_int 2454267026 [0x92492492])) -1 (nil))
>>
>> My other option is to disable subreg-splitting on my port, but I
>> wonder what adverse effects it could have on 64bits integral code.
>>
>> What is the correct way to deal with this?
>
> Setting MODES_TIEABLE_P is the right way to control lower-subreg. Your
> problem lies elsewhere. gcc requires that all simple moves be handled
> by the backend one way or another, and the above insn is a simple move.
> Why is it not recognized? Is register 136 a pseudo or a hard register?
> If a hard floating point register, how do you load a constant into a
> floating point register?
136 is a pseudo. I have movdf and movsf patterns that accepts
constants. I'm not sure what happens. Also, strictly speaking, the
unrecognized pattern above is a SI move and not a floating point move,
isn't it?
I managed to get thinks going by constraining MODES_TIEABLE_P and
adding 2 patterns of the form:
[(set (subreg:SI (match_operand:DF 0 "register_operand" "=r") 0)
(match_operand 1 "immediate_operand" "i"))]
and
[(set (subreg:SI (match_operand:DF 0 "register_operand" "=r") 4)
(match_operand 1 "immediate_operand" "i"))]
This result lead me to think that MODES_TIEABLE_P also controls what
kind of subreg expressions are allowed and thus prevented the initial
pattern from being matched, is that true? Note that splitting DF
values in SI subparts is exactly what I prevented by my
MODES_TIEABLE_P modification.
In the current form, all the testsuite passes, and I get the code
generation I want, but I'm not really fond of the (set (subreg:SI
(reg:DF) ...) rules that I added.
Thanks,
Fred
