This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ARM] Fix a performance regression from the fix for PR49030
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at linaro dot org>
- To: gcc-patches at gcc dot gnu dot org, richard dot sandiford at linaro dot org
- Date: Wed, 21 Sep 2011 16:12:29 +0100
- Subject: Re: [ARM] Fix a performance regression from the fix for PR49030
- References: <g4vcsnmwv3.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com>
On 20 September 2011 09:38, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> My fix for PR49030 had the unintended side-effect of forcing libcalls
> to be used for some DImode comparisons. ?The problem (which I should
> have noticed at the time, sorry) is that arm_comparison_operator is
> used for both expanders and insns. ?The patch fixed the definition
> for insns, but made it too tight for expanders.
>
> The expanders can't use the generic comparison_operator predicate
> because ARM has no support for UNEQ and LTGT. ?So this patch introduces
> an expandable_comparison_operator that the expanders can use instead.
>
> I've left incscc and decscc using arm_comparison_operator, since they
> expand directly into instructions without any manipulation. ?These
> expanders appear to be dead anyway, so I'd be happy to remove them if
> that seems better. ?It should probably be a separate patch though.
>
OK as a followup patch.
> Otherwise, all expanders use expandable_comparison_operator instead.
> This restores the previous behaviour for them, and I went through each
> one to try to make sure that it was handled correctly.
>
> Tested on arm-linux-gnueabi. ?OK to install?
This is OK. Please add some tests for FPmode comparisons as well
just so that we catch these early next time.
cheers
Ramana