This function has a long history, which is worth telling:

• It was added in https://github.com/meta-rust/meta-rust/commit/ba16b5c39e3a23452a98a88d1ca58da0448f97f0 with the same idea: Optimize for 32-bit Core2 or 64-bit Core i7 if possible, otherwise select the closest generic x86 CPU, otherwise select a completely generic CPU. This implementation had two flaws:
  • It used a single translation table for two variables (TUNE_PKGARCH and TRANSLATED_TARGET_ARCH), making it hard to guess where a certain value comes from and whether one is still needed.
  • It used TUNE_PKGARCH, which is an arbitrary CPU description that everyone can make up with an own machine definition. Hence, this list can never be complete.
• TUNE_PKGARCH was replaced by PACKAGE_ARCH in https://github.com/meta-rust/meta-rust/commit/97fcc5db567e16e15a16b7b0ed5707ebc480d97e to "ensure older processors can run created executables when building targets that have newer features". In my opinion, this change made no sense at all:
  • If you choose e.g. "corei7-64" as your target, Yocto will obviously build all applications for Core i7 and later only. People are supposed to select a generic target if they want generic applications that can run on old and new processors.
  • TUNE_PKGARCH is no longer checked, but the translation table kept its entries for "core2-32" and "corei7-64". These cases just cannot happen anymore.
• MIPS support was added in https://github.com/meta-rust/meta-rust/commit/f02df59eea737b1ee0e35db213e27201c5427622 and now evaluates a third variable TUNE_FEATURES to decide on the CPU.
• PowerPC support was added in https://github.com/meta-rust/meta-rust/commit/68d6bce6091621f738ad1ef75af7dcebe4df5d35, but it translates "powerpc" to "powerpc" instead of "ppc" (which is the correct Rust/LLVM internal CPU name).

My PR now changes llvm_cpu to first evaluate the TUNE_CCARGS variable. Every machine definition that wants to optimize for a particular CPU puts a -march flag for GCC here. My code translates this to a Rust/LLVM CPU definition (1:1 mappings so far, but this is not guaranteed!). This covers machines defined in the meta-pcengines layer ("pcengines-apu2" sets -march=btver2), the meta-intel layer ("core2-32" sets -march=core2, "corei7-64" sets -march=nehalem, "skylake-64" sets -march=skylake), and it should cover the MIPS cases that were previously handled via the TUNE_FEATURES variable. Note that this list still needs to be maintained, but -march flags are standardized whereas machine names are arbitrary.

If no match has been found for the -march flag, I check the TRANSLATED_TARGET_ARCH variable and return a generic CPU for that architecture. This covers remaining x86 and MIPS cases where no specific CPU is set, and also fixes the previously wrong PowerPC CPU name.

If no match has been found for TRANSLATED_TARGET_ARCH either, I return "generic". This is the case for e.g. ARM where optimization has been entirely implemented via feature flags.

fair enough

Bumps enumflags2 from 0.6.2 to 0.6.4. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/NieDzejkob/enumflags2/releases">enumflags2's releases</a>.</em></p> <blockquote> <h2>Release 0.6.4</h2> <ul> <li>implement <code>Eq</code>, <code>Hash</code> and <code>Extend</code> for <code>BitFlags</code></li> <li>expose a RawBitFlags proxy trait to make blanket implementations possible</li> <li>the implementation of <code>FromIterator</code> is now 15% faster in some use cases</li> </ul> <h2>Release 0.6.3</h2> <p>Modify the generated code slightly to avoid triggerring the <code>trivial_numeric_casts</code> lint.</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/NieDzejkob/enumflags2/commits/v0.6.4">compare view</a></li> </ul> </details> <br />

You can trigger a rebase of this PR by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

Superseded by #21.

Bumps enumflags2 from 0.6.2 to 0.7.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/NieDzejkob/enumflags2/releases">enumflags2's releases</a>.</em></p> <blockquote> <p>Release 0.7.0</p> <ul> <li><strong>Breaking change</strong>: instead of <code>#[derive(BitFlags)]</code>, the macro is now <code>#[bitflags]</code></li> <li>when a discriminant isn't provided, the macro will choose an unused bit for you</li> <li>you can now create instances of <code>BitFlags</code> without repeating the name: <code>make_bitflags!(MyFlags::{Foo, Bar})</code> instead of <code>MyFlags::Foo | MyFlags::Bar</code>. Works in a <code>const fn</code>, too!</li> <li>many new APIs that allow working with <code>BitFlags</code> in a <code>const fn</code> despite rustc limitations</li> <li>many improved error messages</li> <li>implementation details do not show up in user documentation anymore</li> <li><strong>Breaking change</strong>: rename the <code>RawBitFlags</code> trait to <code>BitFlag</code> - there's nothing raw about it</li> <li><strong>Breaking change</strong>: the <code>not_literal</code> feature doesn't exist, the relevant functionality is now enabled by default - there is no concern about confusing error messages anymore</li> <li><strong>Breaking change</strong>: the <code>#[repr(u??)]</code> attribute is now required - previously, Rust's default of <code>usize</code> was used, which is a terrible idea for the size of a bitfield</li> <li><strong>Breaking change</strong>: <code>BitFlags::new</code> is now called <code>from_bits_unchecked</code> - <code>new</code> suggests that this is the main, preferred way of creating <code>BitFlags</code>. This is not the case.</li> <li>the value returned by <code>Default::default</code> can now be customized with <code>#[bitflags(default = Foo | Bar)]</code></li> </ul> <h2>Release 0.6.4</h2> <ul> <li>implement <code>Eq</code>, <code>Hash</code> and <code>Extend</code> for <code>BitFlags</code></li> <li>expose a RawBitFlags proxy trait to make blanket implementations possible</li> <li>the implementation of <code>FromIterator</code> is now 15% faster in some use cases</li> </ul> <h2>Release 0.6.3</h2> <p>Modify the generated code slightly to avoid triggerring the <code>trivial_numeric_casts</code> lint.</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/NieDzejkob/enumflags2/commits/v0.7.1">compare view</a></li> </ul> </details> <br />

You can trigger a rebase of this PR by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

</details>

Currently, this is handled by not finding a -march parameter in TUNE_CCARGS and using the translation table for TRANSLATED_TARGET_ARCH instead, where "powerpc64" is translated to "ppc64". If specific CPU optimization based on the -mcpu parameter becomes necessary in the future, someone should add another translation table and loop after the -march loop and translate -mcpu parameters to their Rust/LLVM equivalents there.

As the current PR doesn't break anything related to PowerPC, this can and should be done in a subsequent PR though.

I updated my Yocto project from meta-rust 318fb46863 to 029f1ea6a6. It seems to build fine so far.

As explained in the core ML conversation, the observations on master are rather expected.

https://lists.openembedded.org/g/openembedded-core/topic/80874524#148565

Thanks.