From: mka@chromium.org (Matthias Kaehlcke)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm/arm64: smccc: Use xN for arm64 register constraints with clang
Date: Thu, 5 Apr 2018 12:21:09 -0700 [thread overview]
Message-ID: <20180405192109.GA130399@google.com> (raw)
In-Reply-To: <CAKwvOdkcpxcP5Eb5f1-bJgU0gi4zkbof5WJWz2QbVCNsGBUO3w@mail.gmail.com>
On Thu, Apr 05, 2018 at 06:43:05PM +0000, Nick Desaulniers wrote:
> On Thu, Mar 22, 2018 at 4:58 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> > El Thu, Mar 22, 2018 at 04:19:42PM -0700 Greg Hackmann ha dit:
> > > NAK. There's a reason I didn't send my change upstream.
> > >
> > > As Marc pointed out (https://lkml.org/lkml/2018/3/16/987), the "r"
> > > prefix tells gcc to pick the appropriate register width. "x" makes it
> > > unconditionally use the entire 64-bit register width. Just swapping out
> > > one for the other changes the macro's semantics.
> > >
> > > Unfortunately since this was breaking builds in android-4.14 and we
> > > didn't have an immediate-term fix, I bit the bullet and added the above
> > > commit -- but *only* as a short-term workaround. For the one caller we
> > > currently have in 4.14.y, gcc was using the entire 64-bit width for all
> > > its inputs anyway, so "r" vs. "x" didn't make a difference. But that
> > > might not be true if/when someone introduces other SMCCC 1.1 callers.
> > >
> > > Unfortunately I don't see a better way to deal with this than waiting
> > > for clang to support "r"-style constraints on ARM64.
>
> > Thanks for the clarification! From the other thread
> > (https://lkml.org/lkml/2018/3/1/268) I had the impression that ARM
> > folks saw the option of a mergeable fix.
>
> > Given the fact that clang support for kernel builds is still
> > recent/WIP I guess it's not the end of the world if we have to raise
> > the minimum clang version to 7.x for newer kernels.
>
>
> Manoj fixed this in:
> https://reviews.llvm.org/rL328829
> https://bugs.llvm.org/show_bug.cgi?id=36862
>
> Looks set to ride the Clang 6.0 train. mka@ if you're planning another
> state of the union email, it would be good to note the clang 6.0
> requirement for arm64.
>
> Is there anything left to do here?
We should be good, unless somebody wants to look into a patch that
fixes clang pre-6.0.1 builds and doesn't look too ugly.
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Kaehlcke <mka@chromium.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Greg Hackmann <ghackmann@google.com>,
marc.zyngier@arm.com, Catalin Marinas <catalin.marinas@arm.com>,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org,
LKML <linux-kernel@vger.kernel.org>,
Christoffer Dall <christoffer.dall@linaro.org>,
Dave.Martin@arm.com, Andrey Konovalov <andreyknvl@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Kostya Serebryany <kcc@google.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Manoj Gupta <manojgupta@google.com>
Subject: Re: [PATCH] arm/arm64: smccc: Use xN for arm64 register constraints with clang
Date: Thu, 5 Apr 2018 12:21:09 -0700 [thread overview]
Message-ID: <20180405192109.GA130399@google.com> (raw)
In-Reply-To: <CAKwvOdkcpxcP5Eb5f1-bJgU0gi4zkbof5WJWz2QbVCNsGBUO3w@mail.gmail.com>
On Thu, Apr 05, 2018 at 06:43:05PM +0000, Nick Desaulniers wrote:
> On Thu, Mar 22, 2018 at 4:58 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> > El Thu, Mar 22, 2018 at 04:19:42PM -0700 Greg Hackmann ha dit:
> > > NAK. There's a reason I didn't send my change upstream.
> > >
> > > As Marc pointed out (https://lkml.org/lkml/2018/3/16/987), the "r"
> > > prefix tells gcc to pick the appropriate register width. "x" makes it
> > > unconditionally use the entire 64-bit register width. Just swapping out
> > > one for the other changes the macro's semantics.
> > >
> > > Unfortunately since this was breaking builds in android-4.14 and we
> > > didn't have an immediate-term fix, I bit the bullet and added the above
> > > commit -- but *only* as a short-term workaround. For the one caller we
> > > currently have in 4.14.y, gcc was using the entire 64-bit width for all
> > > its inputs anyway, so "r" vs. "x" didn't make a difference. But that
> > > might not be true if/when someone introduces other SMCCC 1.1 callers.
> > >
> > > Unfortunately I don't see a better way to deal with this than waiting
> > > for clang to support "r"-style constraints on ARM64.
>
> > Thanks for the clarification! From the other thread
> > (https://lkml.org/lkml/2018/3/1/268) I had the impression that ARM
> > folks saw the option of a mergeable fix.
>
> > Given the fact that clang support for kernel builds is still
> > recent/WIP I guess it's not the end of the world if we have to raise
> > the minimum clang version to 7.x for newer kernels.
>
>
> Manoj fixed this in:
> https://reviews.llvm.org/rL328829
> https://bugs.llvm.org/show_bug.cgi?id=36862
>
> Looks set to ride the Clang 6.0 train. mka@ if you're planning another
> state of the union email, it would be good to note the clang 6.0
> requirement for arm64.
>
> Is there anything left to do here?
We should be good, unless somebody wants to look into a patch that
fixes clang pre-6.0.1 builds and doesn't look too ugly.
next prev parent reply other threads:[~2018-04-05 19:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-22 21:27 [PATCH] arm/arm64: smccc: Use xN for arm64 register constraints with clang Matthias Kaehlcke
2018-03-22 21:27 ` Matthias Kaehlcke
2018-03-22 22:26 ` Nick Desaulniers
2018-03-22 22:26 ` Nick Desaulniers
2018-03-22 22:44 ` Matthias Kaehlcke
2018-03-22 22:44 ` Matthias Kaehlcke
2018-03-22 23:19 ` Greg Hackmann
2018-03-22 23:19 ` Greg Hackmann
2018-03-22 23:58 ` Matthias Kaehlcke
2018-03-22 23:58 ` Matthias Kaehlcke
2018-04-05 18:43 ` Nick Desaulniers
2018-04-05 18:43 ` Nick Desaulniers
2018-04-05 19:21 ` Matthias Kaehlcke [this message]
2018-04-05 19:21 ` Matthias Kaehlcke
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=20180405192109.GA130399@google.com \
--to=mka@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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.