This is the mail archive of the
mailing list for the GCC project.
Re: new ARM shift pattern for double
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Nicolas Pitre <nico at cam dot org>, mark at codesourcery dot com
- Cc: gcc-patches at gcc dot gnu dot org, Richard Earnshaw <rearnsha at arm dot com>
- Date: Tue, 11 Nov 2003 15:36:48 +0000
- Subject: Re: new ARM shift pattern for double
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> This patch is two fold:
> 1) provide better shift patterns for DI values when the shift count is
> const 1.
> 2) prevent using iwmmxt insns (or cirrus in the ashldi3 case) for shifting
> DI values when shift count is constant since the default strategy does
> a better job already as arguments don't have to be moved back and
> forth between normal and coprocessor regs.
> Ideally neither 1 nor 2 should happen if the value to shift is known already
> siting in an iwmmxt/cirrus register, but since pattern matching happens
> before register allocation this doesn't seem to be simple. So this patch
> assume it's not which is by far the common case anyway.
> There used to be a ashldi3 template mainly for use with the cirrus pattern
> before but I'm failing to find a reason for its presence. The other iwmmxt
> patterns didn't seem to need such construct at all.
> Testing and inspection of generated code for cirrus, iwmmxt and plain ARM
> targets with various optimization levels show desired effect.
> <date> Nicolas Pitre <firstname.lastname@example.org>
> * config/arm/arm.md (ashldi3, arm_ashldi3_1bit, ashrdi3,
> arm_ashrdi3_1bit, lshrdi3, arm_lshrdi3_1bit): New patterns.
> * config/arm/iwmmxt.md (ashrdi3_iwmmxt): Renamed from ashrdi3.
> (lshrdi3_iwmmxt): Renamed from lshrdi3.
> * config/arm/arm.c (IWMMXT_BUILTIN2): Renamed argument accordingly.
This is ok, but I think it's getting a bit late in the development process
to include it for 3.4.
I'm not sure whether or not Mark is accepting patches from
non-CodeSourcery folks for the csl-arm-branch, but if he is, then I think
this might be ok there.
You should also note that ashift (x const) is normally canonicalized by
the optimizer to mult (x (2<<(const-1))). We probably ought to have a
similar matcher for arm_multdi3_const2.