public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Christophe Lyon <christophe.lyon@linaro.org>
To: Sudakshina Das <sudi.das@arm.com>
Cc: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>,
		"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>,
		Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	nd <nd@arm.com>
Subject: Re: [PATCH][ARM][PR82989] Fix unexpected use of NEON instructions for shifts
Date: Wed, 21 Mar 2018 08:59:00 -0000	[thread overview]
Message-ID: <CAKdteOa+kLm_yBPBjE4K9dY9J1wBukFO55i77LfNHZBd-Lp9_w@mail.gmail.com> (raw)
In-Reply-To: <aefb3c39-4c73-b09f-aaad-52d810bc320e@arm.com>

On 20 March 2018 at 11:58, Sudakshina Das <sudi.das@arm.com> wrote:
> Hi
>
> On 20/03/18 10:03, Richard Earnshaw (lists) wrote:
>>
>> On 14/03/18 10:11, Sudakshina Das wrote:
>>>
>>> Hi
>>>
>>> This patch fixes PR82989 so that we avoid NEON instructions when
>>> -mneon-for-64bits is not enabled. This is more of a short term fix for
>>> the real deeper problem of making and early decision of choosing or
>>> rejecting NEON instructions. There is now a new ticket PR84467 to deal
>>> with the longer term solution.
>>> (Please refer to the discussion in the bug report for more details).
>>>
>>> Testing: Bootstrapped and regtested on arm-none-linux-gnueabihf and
>>> added a new test case based on the test given on the bug report.
>>>
>>> Ok for trunk and backports for gcc-7 and gcc-6 branches?
>>>
>>
>> OK for trunk.  Please leave it a couple of days before backporting to
>> ensure that the testcase doesn't tickle any multilib issues.
>>
>> R.
>
>
> Thanks. Committed to trunk as r258677. Will wait a week for backporting.
>
> Sudi
>

Hi Sudi,

I've noticed that:
FAIL:    gcc.target/arm/pr82989.c scan-assembler-times lsl\\tr[0-9]+,
r[0-9]+, r[0-9] 2
FAIL:    gcc.target/arm/pr82989.c scan-assembler-times lsr\\tr[0-9]+,
r[0-9]+, r[0-9] 2
on target armeb-none-linux-gnueabihf
--with-mode thumb
--with-cpu cortex-a9
--with-fpu neon-fp16

The tests pass when using --with-mode arm

Can you check?

Thanks

Christophe

>
>>
>>> Sudi
>>>
>>>
>>> *** gcc/ChangeLog ***
>>>
>>> 2018-03-14  Sudakshina Das  <sudi.das@arm.com>
>>>
>>>      * config/arm/neon.md (ashldi3_neon): Update ?s for constraints
>>>      to favor GPR over NEON registers.
>>>      (<shift>di3_neon): Likewise.
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>>
>>> 2018-03-14  Sudakshina Das  <sudi.das@arm.com>
>>>
>>>      * gcc.target/arm/pr82989.c: New test.
>>>
>>> pr82989.diff
>>>
>>>
>>> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
>>> index 6a6f5d7..1646b21 100644
>>> --- a/gcc/config/arm/neon.md
>>> +++ b/gcc/config/arm/neon.md
>>> @@ -1180,12 +1180,12 @@
>>>   )
>>>     (define_insn_and_split "ashldi3_neon"
>>> -  [(set (match_operand:DI 0 "s_register_operand"           "= w,
>>> w,?&r,?r,?&r, ?w,w")
>>> -       (ashift:DI (match_operand:DI 1 "s_register_operand" " 0w, w, 0r,
>>> 0,  r, 0w,w")
>>> -                  (match_operand:SI 2 "general_operand"    "rUm, i,  r,
>>> i,  i,rUm,i")))
>>> -   (clobber (match_scratch:SI 3                                    "= X,
>>> X,?&r, X,  X,  X,X"))
>>> -   (clobber (match_scratch:SI 4                                    "= X,
>>> X,?&r, X,  X,  X,X"))
>>> -   (clobber (match_scratch:DI 5                                    "=&w,
>>> X,  X, X,  X, &w,X"))
>>> +  [(set (match_operand:DI 0 "s_register_operand"           "= w, w, &r,
>>> r, &r, ?w,?w")
>>> +       (ashift:DI (match_operand:DI 1 "s_register_operand" " 0w, w, 0r,
>>> 0,  r, 0w, w")
>>> +                  (match_operand:SI 2 "general_operand"    "rUm, i,  r,
>>> i,  i,rUm, i")))
>>> +   (clobber (match_scratch:SI 3                                    "= X,
>>> X, &r, X,  X,  X, X"))
>>> +   (clobber (match_scratch:SI 4                                    "= X,
>>> X, &r, X,  X,  X, X"))
>>> +   (clobber (match_scratch:DI 5                                    "=&w,
>>> X,  X, X,  X, &w, X"))
>>>      (clobber (reg:CC_C CC_REGNUM))]
>>>     "TARGET_NEON"
>>>     "#"
>>> @@ -1276,7 +1276,7 @@
>>>   ;; ashrdi3_neon
>>>   ;; lshrdi3_neon
>>>   (define_insn_and_split "<shift>di3_neon"
>>> -  [(set (match_operand:DI 0 "s_register_operand"            "= w,
>>> w,?&r,?r,?&r,?w,?w")
>>> +  [(set (match_operand:DI 0 "s_register_operand"            "= w, w, &r,
>>> r, &r,?w,?w")
>>>         (RSHIFTS:DI (match_operand:DI 1 "s_register_operand" " 0w, w, 0r,
>>> 0,  r,0w, w")
>>>                     (match_operand:SI 2 "reg_or_int_operand" "  r, i,  r,
>>> i,  i, r, i")))
>>>      (clobber (match_scratch:SI 3
>>> "=2r, X, &r, X,  X,2r, X"))
>>> diff --git a/gcc/testsuite/gcc.target/arm/pr82989.c
>>> b/gcc/testsuite/gcc.target/arm/pr82989.c
>>> new file mode 100644
>>> index 0000000..1295ee6
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/arm/pr82989.c
>>> @@ -0,0 +1,38 @@
>>> +/* PR target/82989 */
>>> +/* { dg-do compile } */
>>> +/* { dg-require-effective-target arm_neon_ok } */
>>> +/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } {
>>> "-mcpu=*" } { "-mcpu=cortex-a8" } } */
>>> +/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } {
>>> "-mfpu=*" } { "-mfpu=neon" } } */
>>> +/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } {
>>> "-mfloat-abi=*" } { "-mfloat-abi=hard" } } */
>>> +/* { dg-options "-O2 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=hard" } */
>>> +/* { dg-add-options arm_neon } */
>>> +
>>> +typedef unsigned long long uint64_t;
>>> +
>>> +void f_shr_imm (uint64_t *a )
>>> +{
>>> +  *a += *a >> 32;
>>> +}
>>> +/* { dg-final { scan-assembler-not "vshr*" } } */
>>> +
>>> +void f_shr_reg (uint64_t *a, uint64_t b)
>>> +{
>>> +  *a += *a >> b;
>>> +}
>>> +/* { dg-final { scan-assembler-not "vshl*" } } */
>>> +/* Only 2 times for f_shr_reg. f_shr_imm should not have any.  */
>>> +/* { dg-final { scan-assembler-times {lsr\tr[0-9]+, r[0-9]+, r[0-9]} 2 }
>>> } */
>>> +
>>> +void f_shl_imm (uint64_t *a)
>>> +{
>>> +  *a += *a << 32;
>>> +}
>>> +/* { dg-final { scan-assembler-not "vshl*" } } */
>>> +
>>> +void f_shl_reg (uint64_t *a, uint64_t b)
>>> +{
>>> +  *a += *a << b;
>>> +}
>>> +/* { dg-final { scan-assembler-not "vshl*" } } */
>>> +/* Only 2 times for f_shl_reg. f_shl_imm should not have any.  */
>>> +/* { dg-final { scan-assembler-times {lsl\tr[0-9]+, r[0-9]+, r[0-9]} 2 }
>>> } */
>>>
>>
>

  reply	other threads:[~2018-03-21  8:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-14 10:55 Sudakshina Das
2018-03-20 10:08 ` Richard Earnshaw (lists)
2018-03-20 11:05   ` Sudakshina Das
2018-03-21  8:59     ` Christophe Lyon [this message]
2018-03-21 12:01       ` Sudakshina Das
2018-03-27 16:46         ` Sudakshina Das

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=CAKdteOa+kLm_yBPBjE4K9dY9J1wBukFO55i77LfNHZBd-Lp9_w@mail.gmail.com \
    --to=christophe.lyon@linaro.org \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kyrylo.tkachov@foss.arm.com \
    --cc=nd@arm.com \
    --cc=sudi.das@arm.com \
    /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).