Hi all,
I am currently adding floating point support for a private target (for
GCC 4.1.1). i am having some problems with register allocation.
In SF mode, i have specified to the compiler that it can use both
floating point registers as well as data registers. For all move
instructions in SF mod
Rohit Arul Raj wrote:
(define_insn "movsf_store"
[(set (match_operand:SF 0 "memory_operand" "=m")
(match_operand:SF 1 "float_reg""f"))]
You must have a single movsf define_insn that accepts all alternatives
so that reload will work. You can't have separate define_insns for
movsf an
Hi all,
I had a single movsf insn that accepts all alternatives for the reload to work.
(define_insn "movsf"
[(set (match_operand:SF 0 "nonimmediate_operand" "=f,m,f,f,d,d")
(match_operand:SF 1 "general_operand" "m,f,f,d,f,i"))
]
But for moving an immediate value,
On 14 March 2007 21:21, Jim Wilson wrote:
> Rohit Arul Raj wrote:
>> (define_insn "movsf_store"
>> [(set (match_operand:SF 0 "memory_operand" "=m")
>> (match_operand:SF 1 "float_reg""f"))]
>
> You must have a single movsf define_insn that accepts all alternatives
> so that reload will w
Dave Korn wrote:
But it is ok to use a define_expand (that accepts all alternatives) for
movsf and use that to generate one of several movsf_ insns, isn't it?
No. You have to have a single movsf insn that accepts all constraints.
reload knows that it can fix practically anything by emit
Dave Korn wrote:
But it is ok to use a define_expand (that accepts all alternatives) for
movsf and use that to generate one of several movsf_ insns, isn't it?
Reload doesn't use the move define_expands. It can't. A define_expand
is allowed to do stuff like generate new RTL that would c
Rohit Arul Raj wrote:
But for moving an immediate value, compiler should use a data
register but it is using a floating point register.
Sometimes it is impossible to avoid using an FP reg where we would
prefer to have a data register. This is why reload exists, to fix
things that don't matc
Jim Wilson <[EMAIL PROTECTED]> writes:
> Dave Korn wrote:
>> But it is ok to use a define_expand (that accepts all alternatives) for
>> movsf and use that to generate one of several movsf_ insns, isn't it?
>
> Reload doesn't use the move define_expands. It can't. A define_expand
> is allow
On 16 March 2007 15:30, Richard Sandiford wrote:
> Jim Wilson <[EMAIL PROTECTED]> writes:
>> Dave Korn wrote:
>>> But it is ok to use a define_expand (that accepts all alternatives) for
>>> movsf and use that to generate one of several movsf_ insns, isn't it?
>>
>> Reload doesn't use the mo
Richard Sandiford wrote:
That isn't unconditionally true, is it? reload1.c:gen_reload
uses gen_move_insn, which is just a start_sequence/end_sequence
wrapper for emit_move_insn_1, which in turn calls the move expanders.
Yes, you are right. I over simplified. We can use gen_move_insn when
we
Hi All,
I had a single movsf insn that accepts all alternatives for the reload to work.
(define_insn "movsf"
[(set (match_operand:SF 0 "nonimmediate_operand" "=f,m,f,f,d,d")
(match_operand:SF 1 "general_operand" "m,f,f,d,f,i"))
]
But for the alternative 3, i need a anot
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> I had a single movsf insn that accepts all alternatives for the reload to
> work.
>
> (define_insn "movsf"
> [(set (match_operand:SF 0 "nonimmediate_operand" "=f,m,f,f,d,d")
>(match_operand:SF 1 "general_operand" "m,f,f,d,f,i"))
>
On 11 April 2007 16:48, Rohit Arul Raj wrote:
> Hi All,
>
> I had a single movsf insn that accepts all alternatives for the reload to
> work.
>
> (define_insn "movsf"
> [(set (match_operand:SF 0 "nonimmediate_operand" "=f,m,f,f,d,d")
>(match_operand:SF 1 "general_operand" "m,
13 matches
Mail list logo
