Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Miguel Ojeda]

On Wed, Jul 8, 2026 at 11:40 PM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>
> +        KBUILD_RUSTFLAGS += -Ctarget-cpu=native $(if $(call rust-min-version,109100),-Ctarget-feature=-apxf,)

Hmm... I don't think this was tested?

There is a missing `c` there -- the flag is never going to get passed.

And while it is true that `rustc` knows about the target feature since
1.88.0, it will (sadly) still loudly warn about it:

    warning: unstable feature specified for `-Ctarget-feature`: `apxf`
      |
      = note: this feature is not stably supported; its behavior can
change in the future

Instead, we should be able to do it in the custom target spec, i.e. in
`scripts/generate_rust_target.rs`, assuming `-Ctarget-cpu=native`
enables it and we need to override it. But please double-check the
interaction between those and test that LLVM is actually getting the
right set of features you want.

Finally, we are trying to get rid of the custom target and instead use
flags as soon as possible, so if the flag will be eventually needed,
then it should be stabilized.

To help with that, I have tagged the tracking issue with our Rust for
Linux tag and will raise it to them in our next meeting, but it is
even better if the actual company pings as well:

  https://github.com/rust-lang/rust/issues/139284

I have also added it to our usual live list of features:

  https://github.com/Rust-for-Linux/linux/issues/2

Link: https://github.com/rust-lang/rust/issues/139284
Link: https://github.com/rust-lang/rust/pull/139534

Also Cc'ing rust-for-linux and the maintainers and reviewers.

I hope this helps.

Cheers,
Miguel

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Chang S. Bae]

On 7/9/2026 5:36 AM, Miguel Ojeda wrote:
> On Wed, Jul 8, 2026 at 11:40 PM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>>
>> +        KBUILD_RUSTFLAGS += -Ctarget-cpu=native $(if $(call rust-min-version,109100),-Ctarget-feature=-apxf,)
> 
> Hmm... I don't think this was tested?
> 
> There is a missing `c` there -- the flag is never going to get passed.

Ouch. :(

> 
> And while it is true that `rustc` knows about the target feature since
> 1.88.0, it will (sadly) still loudly warn about it:
> 
>      warning: unstable feature specified for `-Ctarget-feature`: `apxf`
>        |
>        = note: this feature is not stably supported; its behavior can
> change in the future
> 
> Instead, we should be able to do it in the custom target spec, i.e. in
> `scripts/generate_rust_target.rs`, assuming `-Ctarget-cpu=native`
> enables it and we need to override it. But please double-check the
> interaction between those and test that LLVM is actually getting the
> right set of features you want.

I did some investigation [*] into the APX code generation across Rust 
versions. A few notable observations:

  * Rust 1.88 is the first release to recognizes the apxf target feature.
    Prior to that, when LLVM supports APX, target-cpu=native appears to
    allow APX code generation.
  * Starting with Rust 1.95, target-cpu=native no longer appears to
    enable APX instruction generation even without explicitly disabling
    apxf. However, this seems to be implementation-specific and could
    change in future releases.
  * Passing target-feature=-apxf currently emits the warning you quoted
    because the feature is still unstable. Using the generated target
    JSON avoids the warning but Rust versions prior to 1.93 instead
    produce another noise:

    '-apxf' is not a recognized feature for this target ...

Given that, the goal here is to disable APX without build warnings. Rust
1.93 needs to be the minimum version via the generated target JSON.

> 
> Finally, we are trying to get rid of the custom target and instead use
> flags as soon as possible, so if the flag will be eventually needed,
> then it should be stabilized.
> 
> To help with that, I have tagged the tracking issue with our Rust for
> Linux tag and will raise it to them in our next meeting, but it is
> even better if the actual company pings as well:
> 
>    https://github.com/rust-lang/rust/issues/139284
> 
> I have also added it to our usual live list of features:
> 
>    https://github.com/Rust-for-Linux/linux/issues/2
> 
> Link: https://github.com/rust-lang/rust/issues/139284
> Link: https://github.com/rust-lang/rust/pull/139534
> 
> Also Cc'ing rust-for-linux and the maintainers and reviewers.
> 
> I hope this helps.
Indeed. This is very helpful!

Thanks,
Chang

[*]:
https://github.com/intel/apx/blob/study_rust-apxf/study_rust-apxf.md

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Miguel Ojeda]

On Wed, Jul 15, 2026 at 12:15 AM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>
>     JSON avoids the warning but Rust versions prior to 1.93 instead
>     produce another noise:
>
>     '-apxf' is not a recognized feature for this target ...

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

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`.

Also, I saw in your file:

  "The generated `rust/core.o` object was selected as the insepction target
    because it appears to represent the core Rust support built into
the kernel."

To clarify, that object file is "just" the standard library. Which is
definitely a good target to inspect, but since you scripted this
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?

I hope that helps!

> Indeed. This is very helpful!

You're welcome!

Cheers,
Miguel

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Chang S. Bae]

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

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Miguel Ojeda]

On Fri, Jul 31, 2026 at 10:46 PM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>
> 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.

Does it mean it could be the "OR" of those two?

i.e. it sounds like we could avoid having to pick one or the other.

Thanks for double-checking that and doing the analysis, I appreciate
it! Figuring out the precise version gates for this sort of thing is
always informative on its own.

Cheers,
Miguel

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Chang S. Bae]

On 7/31/2026 1:57 PM, Miguel Ojeda wrote:
> 
> Does it mean it could be the "OR" of those two?
> 
> i.e. it sounds like we could avoid having to pick one or the other.
Yes, you're right.

Thanks,
Chang