This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ARM] Improve cond_exec opportunities for immediate shifts for -mrestrict-it
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Kyrylo Tkachov <Kyrylo dot Tkachov at arm dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Tue, 10 Sep 2013 14:32:40 +0100
- Subject: Re: [PATCH][ARM] Improve cond_exec opportunities for immediate shifts for -mrestrict-it
- Authentication-results: sourceware.org; auth=none
- References: <014701cead7a$3d242f40$b76c8dc0$ at tkachov@arm.com> <522ED6F6 dot 6070102 at arm dot com> <000501ceae27$3e0b0430$ba210c90$ at arm dot com>
On 10/09/13 14:11, Kyrylo Tkachov wrote:
>> On 09/09/13 17:32, Kyrylo Tkachov wrote:
>>> Hi all,
>>>
>>> Shift operations with an immediate can generate a 16-bit encoding when
>>> the immediate is 5-bit wide, i.e. in the range [0-31]. Therefore we
>>> can use them in IT blocks even with the -mrestrict-it rules.
>>>
>>> I decided to reuse the "N" constraint with a slight modification by
>>> removing the !TARGET_32BIT condition from it. The "N" constraint is
>>> only used in a few patterns that are predicated by TARGET_THUMB1
>>> anyway, so there's no reason for the constraint to check for that as well.
>>>
>>
>> Hmm, I see no reason why you can't use the M constraint as ARM does.
>
> Ok, it seems that the shift_operator predicate takes care of the validation.
> It seems we can indeed reuse "M" and I notice it's also used in thumb2_shiftsi3_short
> to generate 16-bit shifts.
>
> How about this then?
>
> Tested arm-none-eabi on model with -march=armv8-a.
>
> Kyrill
>
> 2013-09-10 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
>
> * config/arm/arm.md (arm_shiftsi3): New alternative l/l/M.
>
> 2013-09-10 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
>
> * gcc.target/arm/thumb-ifcvt-2.c: New test.
>
>
OK.
R.