Rust for Linux List
 help / color / mirror / Atom feed
From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@kernel.org,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com, "Omar Avelar" <omar.avelar@intel.com>,
	stable@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	rust-for-linux <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions
Date: Fri, 31 Jul 2026 13:46:03 -0700	[thread overview]
Message-ID: <fbbe2b57-19de-4480-b0c6-f44a6007a38f@intel.com> (raw)
In-Reply-To: <CANiq72kn8F-pnd-YxBiPN9nr02jagRk4NL-3vyX1tERCQjqNHA@mail.gmail.com>

Hi Miguel,

First, sorry for my delayed response.

On 7/15/2026 3:30 AM, Miguel Ojeda wrote:
> 
> I think that warning may be coming from LLVM, not Rust, so it may
> depend not on the Rust version, but on the LLVM backend being used
> (Rust compilers support several major LLVM versions).
> 
> So I would recommend double-checking that -- and if so, perhaps you
> may need to restrict the LLVM backend version. In case you need them,
> we have nowadays e.g.
> 
>      CONFIG_RUSTC_LLVM_VERSION
>      CONFIG_RUSTC_LLVM_MAJOR_VERSION

The backend LLVM does not recognize apxf in the target attribute. OTOH, 
Clang appears to translate -mapxf into the backend readables [1]:

   egpr,push2pop2,ppx,ndd,ccmp,nf,cf,zu,jmpabs

Support for the apxf attribute looks to be merged about two weeks ago 
[2], and which is also found in the LLVM 23 RC tree.

Given that one option would be relax the rustc version while tightening 
the backend like:

  Option 1: RUSTC_VERSION >= 108800 && RUSTC_LLVM_MAJOR_VERSION >= 23

Or, simply like the previous:

  Option2: RUSTC_VERSION >= 109301

Since the rustc front does no longer emits the `apxf` attribute starting 
from 1.93. Also, 1.93 requires at least LLVM 21 which already supports APX.

[1] 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Options/Options.td#L7483
[2] https://github.com/llvm/llvm-project/pull/184078


> Also, from that
> https://github.com/intel/apx/blob/study_rust-apxf/study_rust-apxf.md,
> I notice you checked object files, which is a good check, but what I
> meant is to check the LLVM module attributes in the LLVM IR emitted
> from the Rust compiler.
> 
> For instance, if I do:
> 
>    https://godbolt.org/z/sMaajjYao
> 
> I see:
> 
>      +egpr,+push2pop2,+ppx,+ndd,+ccmp,+cf,+nf,+zu
> 
> being added to the LLVM module attributes when I pass a `+apxf`.

I see. --emit=llvm-ir looks to generate .ll files where target-features= 
is readable. Thanks for the clarification!

> anyway, I would suggest checking others. In fact, you could even
> inspect all and filter them out by the language DWARF tag. Or perhaps
> you can just do it for every single object, since the C ones are
> expected to behave the same, no?
> 

Yeah, I could check obj files running the below for example. Both LLVM 
and GCC builds appear free from EGPR use when with Option 2 above.

$ find . -type f -name "*.o" -print0 | xargs -0 -n 1 ./check_egprs.sh
$ cat check_egprs.sh
   egpr_refs=$(objdump -d --no-show-raw-insn $1 | \
     sed -E 's/^[[:space:]]+[0-9a-fA-F]+:[[:space:]]+//' | \
     grep -E 
'%r16|%r17|%r18|%r19|%r20|%r21|%r22|%r23|%r24|%r25|%r26|%r27|%r28|%r29|%r30|%r31' 
| \
     wc -l)

   if [ $egpr_refs != 0 ] ; then
     echo "Fail: $1, $egpr_refs EGPRs"
   fi

Thanks,
Chang


  reply	other threads:[~2026-07-31 20:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260708211435.402426-1-chang.seok.bae@intel.com>
2026-07-09 12:36 ` [PATCH] x86/build/64: Prevent native builds from generating APX instructions Miguel Ojeda
2026-07-14 22:15   ` Chang S. Bae
2026-07-15 10:30     ` Miguel Ojeda
2026-07-31 20:46       ` Chang S. Bae [this message]
2026-07-31 20:57         ` Miguel Ojeda
2026-07-31 21:15           ` Chang S. Bae

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=fbbe2b57-19de-4480-b0c6-f44a6007a38f@intel.com \
    --to=chang.seok.bae@intel.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=bp@alien8.de \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=gary@garyguo.net \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=omar.avelar@intel.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tglx@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=work@onurozkan.dev \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox