This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ARM] NEON DImode not
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Stubbs <ams at codesourcery dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "patches at linaro dot org" <patches at linaro dot org>
- Date: Thu, 01 Mar 2012 17:07:14 +0000
- Subject: Re: [PATCH][ARM] NEON DImode not
- References: <4F4E3AA5.1070804@codesourcery.com> <4F4E67B3.8050002@arm.com> <4F4F7226.6070809@codesourcery.com>
On 01/03/12 12:57, Andrew Stubbs wrote:
> On Wed 29 Feb 2012 18:00:19 GMT, Richard Earnshaw wrote:
>> Why can't we have a single insn that deals with the have-neon and
>> dont-have-neon cases?
>
> Sorry, I'm not sure I follow?
>
> There's one insn for the have-neon case, and one for the
> don't-have-neon. The expander is necessary to prevent gen_one_cmpldi2
> locking recog to a disabled pattern (it caches the recog result, I think).
>
> It would be possible to have the arm.md insn emit NEON instructions, but
> that's not the usual practice, I think? The neon.md isns could also emit
> arm/thumb2 instructions, but there's no real point since there are
> already two different splitters for that.
>
> Andrew
>
The RTL part of one_cmpldi2_internal and one_cmpldi2_neon are the same.
Given that we now have controls to determine when an alternative is
enabled it's generally better to have just one pattern here and turn on
the alternatives that are suitable rather than having multiple patterns.
You're already half doing this with the nota8 and onlya8 controls.
R.