Guidance on microarchitecture support with platforms

[Garrett Kajmowicz]

A single compiler for a single architecture (say, x86_64) may support many different microarchitectures underneath. For example, the gcc -march flag can have a major impact on the set of instructions generated. See, eg:
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-march-14

What makes this tricky is that it requires enabling different sets of compiler flags for the entire build process. For $REASONS, I don't want to be passing the copts on the command-line because I'm also going to be supporting multiple "traditional" platforms in a single build operation, all of which are handled via cross-compilation.

I'm trying to figure out the best way to get multi-microarchitecture support working when targeting several CPUs which all use the same compiler.

Ideas I've considered:

1. Add select() statements to add the necessary -march flag to copts for every cc_library() statement which will filter off of constraints from the platform. This makes the BUILD files large and ugly, but at least it uses straight-forward definitions

2. Like #2, but rewrap cc_library in something which determines the environment to add the copts flags automatically. This is similar to what the drake team did here:

https://github.com/RobotLocomotion/drake/blob/master/tools/skylark/drake_cc.bzl

3. Create a separate cc_toolchain (complete with separate config) for each microarchitecture. This allows everything else to Just Work, but requires moving away from the "standard" @platforms:cpu constraints for the platform resolution code to work correctly.

I'm not certain which of these would be the best choice, if there are others I haven't considered, and if there are any good examples of this usecase.

Thanks again!

-     Garrett

[John Cater]

On Fri, Jun 11, 2021 at 4:14 PM Garrett Kajmowicz <garrett....@gmail.com> wrote:

I'm trying to figure out the best way to get multi-microarchitecture support working when targeting several CPUs which all use the same compiler.

Ideas I've considered:

1. Add select() statements to add the necessary -march flag to copts for every cc_library() statement which will filter off of constraints from the platform. This makes the BUILD files large and ugly, but at least it uses straight-forward definitions

This is not a good approach, for the reasons you list, and also because you then can't include any external repositories (because they won't use your copts).

 

2. Like #2, but rewrap cc_library in something which determines the environment to add the copts flags automatically. This is similar to what the drake team did here:

https://github.com/RobotLocomotion/drake/blob/master/tools/skylark/drake_cc.bzl

This has a similar issue as 1.

 

3. Create a separate cc_toolchain (complete with separate config) for each microarchitecture. This allows everything else to Just Work, but requires moving away from the "standard" @platforms:cpu constraints for the platform resolution code to work correctly.

If you care about generating the most optimized code for each microarchitecture, this is the right solution. You can write your cc_toolchain_config rule to allow easily configuring the microarch flags you need, and keep the rest the same, and then define your custom constraints and platforms to allow the builds to work properly.

My advice would be to use the standard x86_64 cpu constraint from the @platforms repository, and to define a new custom microarch constraint setting for the microarchs you are interested in. This will allow your platforms to interoperate with other, non-c++ languages that do not care about the microarchs, but still tune your c++ toolchains appropriately for the platform microarch.

 

John C

[Jingwen Chen]

This is exactly how it's done for Bazel in AOSP today: https://cs.android.com/android/platform/superproject/+/master:build/bazel/platforms/arch/BUILD;l=8-28;drc=9135d6b8a815c91e91c75acec8a0c0c0e45c7127 

 

 

John C

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAOD4_Y44berH65OqC%2BddYqRp6m%3Dmi%3DXNo-iT5m-fu56D_y4G7g%40mail.gmail.com.

[Garrett Kajmowicz]

Thank you for the guidance. I implemented everything pretty-much as you listed and now have everything working.

The compiler is now happy with the limited amount of hand-optimized ASM for each microarchitecture.

On to the next major confusion!

-     Garrett