All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Jamie Cunliffe <Jamie.Cunliffe@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	rust-for-linux@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	steve.capper@arm.com
Subject: Re: [PATCH 1/3] arm64: rust: Enable Rust support for AArch64
Date: Tue, 31 Jan 2023 16:19:06 +0000	[thread overview]
Message-ID: <20230131161905.GC2646@willie-the-truck> (raw)
In-Reply-To: <CANiq72mpzRjT1ZHCHcGrOJ_71eQPR_-WgP=5YfDWDBNR6JNP4w@mail.gmail.com>

On Thu, Jan 26, 2023 at 06:56:01PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 26, 2023 at 5:35 PM Will Deacon <will@kernel.org> wrote:
> >
> > Why do we need to specify this stuff here? LLVM already knows about AArch64
> > and can compute the data-layout string in computeDataLayout(). Can we have
> > the tools figure this out for us instead, please?
> 
> I agree -- the reason we have this for the moment is to provide full
> control of the target spec, in particular for cases where `rustc` may
> not provide enough flags to customize exiting builtin target specs
> and/or may emit warnings for unknown target features etc.
> 
> If it is already enough for arm64 to use e.g. the
> `aarch64-unknown-none` target spec plus flags on top, then we should
> go for that, because that is the end goal: these target spec files are
> unstable in the Rust compiler (and not intended to become stable).

Please confirm that this is the case, but I really think we should be
aiming for that rather than starting off my specifying this stuff manually.

> For context, upstream Rust so far has been willing to merge support
> for flags and target features that we needed, which is great.

One thing I ran into while playing around is that 128-bit types aren't
supported with ffi unless '-A improper-ctypes' is passed. Given that we
use '__uint128_t' to represent the fpsimd state, I think this is probably
something which will crop up as an issue.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Jamie Cunliffe <Jamie.Cunliffe@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	rust-for-linux@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	steve.capper@arm.com
Subject: Re: [PATCH 1/3] arm64: rust: Enable Rust support for AArch64
Date: Tue, 31 Jan 2023 16:19:06 +0000	[thread overview]
Message-ID: <20230131161905.GC2646@willie-the-truck> (raw)
In-Reply-To: <CANiq72mpzRjT1ZHCHcGrOJ_71eQPR_-WgP=5YfDWDBNR6JNP4w@mail.gmail.com>

On Thu, Jan 26, 2023 at 06:56:01PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 26, 2023 at 5:35 PM Will Deacon <will@kernel.org> wrote:
> >
> > Why do we need to specify this stuff here? LLVM already knows about AArch64
> > and can compute the data-layout string in computeDataLayout(). Can we have
> > the tools figure this out for us instead, please?
> 
> I agree -- the reason we have this for the moment is to provide full
> control of the target spec, in particular for cases where `rustc` may
> not provide enough flags to customize exiting builtin target specs
> and/or may emit warnings for unknown target features etc.
> 
> If it is already enough for arm64 to use e.g. the
> `aarch64-unknown-none` target spec plus flags on top, then we should
> go for that, because that is the end goal: these target spec files are
> unstable in the Rust compiler (and not intended to become stable).

Please confirm that this is the case, but I really think we should be
aiming for that rather than starting off my specifying this stuff manually.

> For context, upstream Rust so far has been willing to merge support
> for flags and target features that we needed, which is great.

One thing I ran into while playing around is that 128-bit types aren't
supported with ffi unless '-A improper-ctypes' is passed. Given that we
use '__uint128_t' to represent the fpsimd state, I think this is probably
something which will crop up as an issue.

Will

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

  reply	other threads:[~2023-01-31 16:20 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 16:37 [PATCH 0/3] Rust enablement for AArch64 Jamie Cunliffe
2023-01-25 16:37 ` Jamie Cunliffe
2023-01-25 16:37 ` [PATCH 1/3] arm64: rust: Enable Rust support " Jamie Cunliffe
2023-01-25 16:37   ` Jamie Cunliffe
2023-01-25 19:50   ` Vincenzo Palazzo
2023-01-25 19:50     ` Vincenzo Palazzo
2023-01-25 19:56   ` Vincenzo Palazzo
2023-01-25 19:56     ` Vincenzo Palazzo
2023-01-26 16:35   ` Will Deacon
2023-01-26 16:35     ` Will Deacon
2023-01-26 17:56     ` Miguel Ojeda
2023-01-26 17:56       ` Miguel Ojeda
2023-01-31 16:19       ` Will Deacon [this message]
2023-01-31 16:19         ` Will Deacon
2023-01-31 16:49         ` Björn Roy Baron
2023-01-31 16:49           ` Björn Roy Baron
2023-01-31 18:55         ` Miguel Ojeda
2023-01-31 18:55           ` Miguel Ojeda
2023-04-18 15:06           ` Jamie Cunliffe
2023-04-18 15:06             ` Jamie Cunliffe
2023-01-27 14:09   ` Gary Guo
2023-01-27 14:09     ` Gary Guo
2023-05-02 13:41   ` Asahi Lina
2023-05-02 13:41     ` Asahi Lina
2023-01-25 16:37 ` [PATCH 2/3] arm64: rust: Enable PAC support for Rust Jamie Cunliffe
2023-01-25 16:37   ` Jamie Cunliffe
2023-01-25 19:54   ` Vincenzo Palazzo
2023-01-25 19:54     ` Vincenzo Palazzo
2023-01-25 16:37 ` [PATCH 3/3] arm64: rust: Disable neon and fp target features Jamie Cunliffe
2023-01-25 16:37   ` Jamie Cunliffe
2023-01-25 17:49   ` Miguel Ojeda
2023-01-25 17:49     ` Miguel Ojeda
2023-01-25 19:55   ` Vincenzo Palazzo
2023-01-25 19:55     ` Vincenzo Palazzo
2023-01-26 16:37   ` Will Deacon
2023-01-26 16:37     ` Will Deacon
2023-01-25 18:01 ` [PATCH 0/3] Rust enablement for AArch64 Miguel Ojeda
2023-01-25 18:01   ` Miguel Ojeda
2023-03-07  9:32 ` Asahi Lina
2023-03-07  9:32   ` Asahi Lina
2023-03-07 12:17   ` Miguel Ojeda
2023-03-07 12:17     ` Miguel Ojeda

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=20230131161905.GC2646@willie-the-truck \
    --to=will@kernel.org \
    --cc=Jamie.Cunliffe@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=steve.capper@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 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.