From: Kyrill Tkachov <kyrylo.tkachov@arm.com>
To: James Greenhalgh <james.greenhalgh@arm.com>,
Jim Wilson <jim.wilson@linaro.org>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, AARCH64] make stdarg functions work with +nofp
Date: Tue, 02 Jun 2015 10:45:00 -0000 [thread overview]
Message-ID: <556D87A5.8020808@arm.com> (raw)
In-Reply-To: <20150602094230.GA4502@arm.com>
Hi James, Jim,
On 02/06/15 10:42, James Greenhalgh wrote:
> On Sat, May 23, 2015 at 12:24:00AM +0100, Jim Wilson wrote:
>> The compiler currently ICEs when compiling a stdarg function with
>> +nofp, as reported in PR 66258.
>>
>> The aarch64.md file disables FP instructions using TARGET_FLOAT, which
>> supports both -mgeneral-regs-only and +nofp. But there is code in
>> aarch64.c that checks TARGET_GENERAL_REGS_ONLY. This results in FP
>> instructions when using +nofp, The aarch64.c code needs to use
>> TARGET_FLOAT instead like the md file already does.
>>
>> I can't meaningfully test this with a bootstrap, since the patch has
>> no effect unless I bootstrap with +nofp, and that will fail as gcc
>> contains floating point code.
>>
>> The testsuite already has multiple stdarg tests, so there is no need
>> for another one.
>>
>> I tested this by verifying I get the same results for some simple
>> testcasess with and without the patch, with and without using
>> -mgeneral-regs-only and -mcpu=cortex-a53+nofp.
> This patch doesn't quite look right to me. The cases you change seem
> like they should be (TARGET_FLOAT || TARGET_SIMD), rather than just
> TARGET_FLOAT. In an armv8-a+nofp environment, you still have access to the
> SIMD registers and instructions (reading between the lines on the bug
> report, this is almost certainly not what is intended in Grub!).
I don't think that's quite right. TARGET_SIMD *always* implies TARGET_FP as it is a superset of that functionality.
For the precise relations of them look in aarch64-option-extensions.def.
Turning off fp with +nofp (or -mgeneral-regs-only) always turns off simd while turning off simd
with +nosimd doesn't turn off fp.
Cheers,
Kyrill
>
> Digging a bit deeper in to the ICE in PR66258, it seems to me that
> the problematic pattern is "*movti_aarch64":
>
> (define_insn "*movti_aarch64"
> [(set (match_operand:TI 0
> "nonimmediate_operand" "=r, *w,r ,*w,r ,Ump,Ump,*w,m")
> (match_operand:TI 1
> "aarch64_movti_operand" " rn,r ,*w,*w,Ump,r ,Z , m,*w"))]
> "(register_operand (operands[0], TImode)
> || aarch64_reg_or_zero (operands[1], TImode))"
> "@
> #
> #
> #
> orr\\t%0.16b, %1.16b, %1.16b
> ldp\\t%0, %H0, %1
> stp\\t%1, %H1, %0
> stp\\txzr, xzr, %0
> ldr\\t%q0, %1
> str\\t%q1, %0"
> [(set_attr "type" "multiple,f_mcr,f_mrc,neon_logic_q, \
> load2,store2,store2,f_loadd,f_stored")
> (set_attr "length" "8,8,8,4,4,4,4,4,4")
> (set_attr "simd" "*,*,*,yes,*,*,*,*,*")
> (set_attr "fp" "*,*,*,*,*,*,*,yes,yes")]
> )
>
> Note that the split alternatives are going to unconditionally create
> and emit insns which require TARGET_FLOAT, but the fp attribute is
> not set on those alternatives. Many of the TI mode split patterns
> could be expressed as a umov from vector registers to general purpose
> registers for a TARGET_SIMD target.
>
> Have you investigated this approach at all?
>
> Thanks,
> James
>
next prev parent reply other threads:[~2015-06-02 10:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-23 7:00 Jim Wilson
2015-06-02 9:44 ` James Greenhalgh
2015-06-02 10:45 ` Kyrill Tkachov [this message]
2015-06-02 11:03 ` James Greenhalgh
2015-06-09 5:18 ` Jim Wilson
2015-06-16 8:48 ` James Greenhalgh
2015-06-16 21:05 ` Jim Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=556D87A5.8020808@arm.com \
--to=kyrylo.tkachov@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=james.greenhalgh@arm.com \
--cc=jim.wilson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).