All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <natechancellor@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Nicolas Pitre <nico@fluxnic.net>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Agner <stefan@agner.ch>,
	Russell King <linux@armlinux.org.uk>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: xor-neon: Replace __GNUC__ checks with CONFIG_CC_IS_GCC
Date: Fri, 31 May 2019 13:26:05 -0700	[thread overview]
Message-ID: <20190531202605.GA78113@archlinux-epyc> (raw)
In-Reply-To: <CAKwvOdkyk3qLMPquSZqXCFauTADJU5X9qJi_fhJqbUuCYBH-6Q@mail.gmail.com>

On Fri, May 31, 2019 at 01:06:13PM -0700, Nick Desaulniers wrote:
> On Fri, May 31, 2019 at 12:21 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > clang, I would suggest dropping your patch then, and instead adding
> 
> I disagree.  The minimum version of gcc required to build the kernel
> is 4.6, so the comment about older versions of gcc is irrelevant and
> should be removed.
> 
> Nathan's -Rpass warnings are warning that vectorization was not
> calculated to be profitable **for 1 of the 4 functions** by LLVM.
> Surely we wouldn't disable NEON opts for XOR because 1 of 4 was not
> vectorized?

Well I kept it short but clang warns that all of the loops are not
profitable.

However, the config option for xor-neon.c is CONFIG_XOR_BLOCKS, which
also controls the arm64 implementation. We wouldn't want to disable it
for clang altogether if it works on arm64 fine.

If it turns out to be broken for both, I suppose I would be okay with
disabling CONFIG_XOR_BLOCKS for clang but it should be done in a
separate patch as this one should be applied regardless of clang working
or not (because this warning will appear again when clang is fixed).

Cheers,
Nathan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <natechancellor@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Nicolas Pitre <nico@fluxnic.net>, Stefan Agner <stefan@agner.ch>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] ARM: xor-neon: Replace __GNUC__ checks with CONFIG_CC_IS_GCC
Date: Fri, 31 May 2019 13:26:05 -0700	[thread overview]
Message-ID: <20190531202605.GA78113@archlinux-epyc> (raw)
In-Reply-To: <CAKwvOdkyk3qLMPquSZqXCFauTADJU5X9qJi_fhJqbUuCYBH-6Q@mail.gmail.com>

On Fri, May 31, 2019 at 01:06:13PM -0700, Nick Desaulniers wrote:
> On Fri, May 31, 2019 at 12:21 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > clang, I would suggest dropping your patch then, and instead adding
> 
> I disagree.  The minimum version of gcc required to build the kernel
> is 4.6, so the comment about older versions of gcc is irrelevant and
> should be removed.
> 
> Nathan's -Rpass warnings are warning that vectorization was not
> calculated to be profitable **for 1 of the 4 functions** by LLVM.
> Surely we wouldn't disable NEON opts for XOR because 1 of 4 was not
> vectorized?

Well I kept it short but clang warns that all of the loops are not
profitable.

However, the config option for xor-neon.c is CONFIG_XOR_BLOCKS, which
also controls the arm64 implementation. We wouldn't want to disable it
for clang altogether if it works on arm64 fine.

If it turns out to be broken for both, I suppose I would be okay with
disabling CONFIG_XOR_BLOCKS for clang but it should be done in a
separate patch as this one should be applied regardless of clang working
or not (because this warning will appear again when clang is fixed).

Cheers,
Nathan

  reply	other threads:[~2019-05-31 20:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 23:57 [PATCH] ARM: xor-neon: Replace __GNUC__ checks with CONFIG_CC_IS_GCC Nathan Chancellor
2019-05-28 23:57 ` Nathan Chancellor
2019-05-30 23:00 ` Nick Desaulniers
2019-05-30 23:00   ` Nick Desaulniers
2019-05-31  8:05 ` Arnd Bergmann
2019-05-31  8:05   ` Arnd Bergmann
2019-05-31 18:32   ` Nathan Chancellor
2019-05-31 18:32     ` Nathan Chancellor
2019-05-31 19:21     ` Arnd Bergmann
2019-05-31 19:21       ` Arnd Bergmann
2019-05-31 20:06       ` Nick Desaulniers
2019-05-31 20:06         ` Nick Desaulniers
2019-05-31 20:26         ` Nathan Chancellor [this message]
2019-05-31 20:26           ` Nathan Chancellor
2019-05-31 21:03         ` Arnd Bergmann
2019-05-31 21:03           ` Arnd Bergmann
2019-06-01  0:28           ` Nathan Chancellor
2019-06-01  0:28             ` Nathan Chancellor

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=20190531202605.GA78113@archlinux-epyc \
    --to=natechancellor@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=ndesaulniers@google.com \
    --cc=nico@fluxnic.net \
    --cc=stefan@agner.ch \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.