This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ARM VFP instructions
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Paul Brook <paul at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Richard Earnshaw <rearnsha at arm dot com>, Mark Mitchell <mark at codesourcery dot com>
- Date: Thu, 29 Jan 2004 17:00:34 +0000
- Subject: Re: ARM VFP instructions
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
paul@codesourcery.com said:
> The attached patch implements code generation for the ARM VFP11
> floating point corocessor.
> It currently uses the standard calling conventions. Implementation of
> the enhanced VFP calling convention will come later.
> Tested with cross-compiler/simulator on arm-none-elf.
> I'm aware of the following unaddressed issues:
> - It sometimes uses IP as a scratch register in function epilogues.
> Is this safe?
It ought to be (with possible exceptions during tail-calling).
> - The exact stack frame layout is implementation dependent. The code should
> be work with any implementation. However stack frame debug info (and
> unwind info?) might be a bit off.
I wouldn't worry about anything other than FSTMX standard format 1.
> - The rtx_costs have not been updated.
> - The scheduler description is fairly basic. It does not
> correctly model fmstat, input register interlocks (caused by
> exception requirements), or integer core resources for VFP<->ARM
> register copies.
> - VFPv1 (w/o fmrrd) and VFPv1xD (w/o double precision) variants are not
> supported.
> Ok?
There are a small number of niggles, but other than the ones that follow,
I think this is OK.
1) The register numbers in the 'alias' arrays need correcting in aout.h
and aof.h (d1 has the same number as d0, and d11 is not spaced correctly).
2) The tied operands in the multiply-accumlate insns: I've always
understood it is best for register allocation purposes to tie adjacent
operand numbers (operand 0 with operand 1, etc), so mulsf3addsf_vfp should
be
(define_insn "*mulsf3addsf_vfp"
[(set (match_operand:SF 0 "s_register_operand" "=w")
(plus:SF (mult:SF (match_operand:SF 2 "s_register_operand" "w")
(match_operand:SF 3 "s_register_operand" "w"))
(match_operand:SF 1 "s_register_operand" "0")))]
"TARGET_ARM && TARGET_HARD_FLOAT && TARGET_VFP"
"fmacs%?\\t%0, %2, %3"
[(set_attr "predicable" "yes")
(set_attr "type" "farith")]
)
Finally, I wonder if there should be a register class for the VFPCC
register (we have one for the CC register).
R.