Hierarchical constraint settings

[fmeum]

This is the discussion for the "Hierarchical constraint settings" proposal.

[katre]

I think all of my suggestions went into the original discussion and PR. The main point (which @fmeum has already added) is that this needs to be very explicit, even if it requires some degree of redundancy on the part of the user: even if //libc/glibc:2.42 requires //libc:glibc, it cannot imply //libc:glibc, and they both need to be specified to prevent any future errors if the constraints are redefined.

(That said, I am slightly unhappy that this example implies both a package and a target named glibc in the libc package: this might end up causing some confusion but I can't think of a better practice for naming. Does bazel still warn about this?)

Overall, I approve this design.

[gregestren]

I also approve.

[DoDoENT]

I'm not the expert here, but I generally have the need for precise specification of microarchitectures. Namely, we have a special platform for "Linux Intel Haswell" that denotes Linux with x86_64-v3 architecture (basically, AVX2 support), and with current Bazel's constraint, this platform does not imply generic Linux x86_64. With this proposal, we could define a constraint setting for x86_64-v3 that would refine @platforms//cpu:x86_64.

Currently, Bazel sees my "Linux Haswell" and "Linux Generic Intel" as totally different and not compatible targets (see my definitions here)

[moroten]

What about multiple refined constraint_values?

constraint_setting(
    name = "x86_64-v3-setting",
    refined_constraint_values = [
        "@platforms//cpu:x86_64",
        ":avx2",
    ],
)

[katre]

What would this mean semantically? The new x86_64-v3-setting values (whatever they are) can are understood to refine both :x86_64 and :avx2, and so all three must be present? I'm unclear on how this is meaningfully different than the current proposal, so if you can explain further what you see as useful, I'd be interested to hear.

[fmeum]

We should distinguish between "declared" and "derived" properties of a platform: A platform declares the v3 constraint value whose setting in turn refines the x86_64 value. Whether a platform has the avx3 feature can then be modelled as ANDed config_settings on all the microarchitecture versions that have this feature - it can be "derived" from platform constraints.

As a result, anyone can define such config_setting_groups. We could add common ones to a central repo for convenience, but they do not have to be shared in the same ways as constraint settings. The new concept of refining doesn't change the situation for such derived properties, it is just meant to close gaps in the system of declared properties by making it impossible to declare inconsistent states.

[moroten]

@fmeum Something bothered me in your design proposal, but it wasn't until now I realised how to (potentially) solve it. The suggestion below tries to address the same scope, so I didn't want to create a new discussion thread.

Alternative suggestion

• Allow constraint_values without any associated constraint_setting.
• Allow constraint_values to "imply" other constraint_values.
  • Either implies should be implicitly added or explicitly required in platform definitions.

constraint_setting(name = "os")
constraint_value(name = ":linux", constraint_setting = ":os")
constraint_value(name = ":windows", constraint_setting = ":os")

constraint_value(name = ":glibc")
constraint_value(name = ":musl")

constraint_value(name = "glibc_2.40", implies = [":glibc"])
constraint_value(name = "glibc_2.41", implies = [":glibc"])
constraint_value(name = "glibc_2.42", implies = [":glibc"])

platform(
    name = "my_platform",
    constraint_values = [
        ":linux",
        # All these versions are installed on my platform.
        ":glibc_2.40",
        ":glibc_2.41",
        ":glibc_2.42",
        # Implies (and needed to be spelled out?)
        ":glibc",
        # Also available on my platform...
        ":musl",
    ],
)

toolchain(
    name = "my_toolchain",
    exec_compatible_with = [":glibc_2.40"],
    target_compatible_with = [":glibc_2.41"],
)

Long description

:linux is incompatible with :windows, so it makes sense to have them coupled to them coupled to the same constraint_setting. On the other hand, :glibc and :musl can both be installed on the same platform. The same applies for :glibc_2.N.

Option 1, no attached constraint_setting.

constraint_value(name = ":glibc")
constraint_value(name = ":musl")

Option 2, multiple=True. What is the benefit of constraint_setting?

constraint_setting(name = "libc", multiple=True)
constraint_value(name = ":glibc", constraint_setting = ":libc")
constraint_value(name = ":musl", constraint_setting = ":libc")

What about a target that requires a certain minimum version of the Linux kernel to run? Instead of using target_compatible_with=[":linux_kernel_6.12"], it should probably be:

Option 1:

constraint_value(
    name = "special_feature_introduced_in_linux_kernel_6.12",
)
constraint_value(
    name = "linux_kernel_6.12",
    implies = [
        ":special_feature_introduced_in_linux_kernel_6.12",
        "@platforms//os:linux",
    ],
)
platform(
    name = "my_platform",
    constraint_values = [
        ":linux_kernel_6.12",
        # Oh well, let's list all the implicit ones...
        "@platforms//os:linux",
        ":special_feature_introduced_in_linux_kernel_6.12",
        # ... lots more features.
    ],
)

Option 2:

constraint_setting(
    name = "various_features",
    multiple = True,
)
constraint_value(
    name = "special_feature_introduced_in_linux_kernel_6.12",
    constraint_setting = ":various_features",  # Any other suggestion of config setting?
)

constraint_value(
    name = ":linux_kernel_6.12",
    implies = [
        ":special_feature_introduced_in_linux_kernel_6.12",
        "@platforms//os:linux",
    ],
)

This will allow for my target to be defined as

rust_library(target_compatible_with = [":special_feature_introduced_in_linux_kernel_6.12"])

Unfortunately, the list of features will just grow over time, so linux_kernel_8.5 will have a long list of constraint_values. How to solve that?

[moroten]

Assume I have a toolchain that builds a binary linked with glibc 2.35. Then that binary will be able to execute on a platform with glibc 2.39. Then we get:

platform(
    constraint_values = [":glibc_2.39"],
)
toolchain(
    exec_compatible_with = [],
    exec_settings = [":supports_glibc_2.33"],  # This doesn't exist. Maybe needed?
    target_compatible_with = [],
    target_settings = [":supports_glibc_2.35"],
)
alias(
    name = "supports_glibc_2.35",
    actual = config_setting_groups(
        any = [":glibc_2.35", ":glibc_2.39", ...],
    ),
)

In this case, I really need toolchain() to get exec_settings (not just target_settings) so that my prebuilt binary for glibc_2.33 can match the platform above. Maybe deprecate {exec,target}_compatible_with and just keep {exec,target}_settings?

[fmeum]

What you can do right now is just register one toolchain for each individual constraint_value, sharing the same actual toolchain implementation. That's tedious, but it's not really different from what selects.config_setting_group does under the hood and could also be abstracted into a macro.

I agree that we probably need better support for such "range constraints" built into Bazel to make this less cumbersome. That is a preexisting problem though and I think that it can be solved independently of the current design. Do you agree with that? Do you see anything about either of the design ideas that would make the situation better or worse?

[moroten]

I agree that the tedious multiple toolchain registration problem can be solved independently. Thank you for clarifying "declared" and "derived" properties, I'll take that into my projects.

What if my platform has both musl and glibc? Then they shouldn't be part of the same constraint_setting, do you agree in that or have I got that wrong?

[fmeum]

They still could belong to the same constraint_setting, just like the glibc versions. For a target platform, you would typically choose one of them. For exec platforms, you could again register multiple platforms that only differ in that particular constraint, but map to the same remote executor.

For musl in particular, exec platforms would probably model it as the absence of a constraint since binaries would typically be linked statically and run anywhere (or use a shell wrapper to use the musl dynamic loader hermetically).

[moroten]

I do have dynamically linked musl binaries. In the general case, constraint_settings is a connection of mutually exclusive constraint_values, but when there is only on enabled/disabled it is easy to make the mistake of putting not-mutually-exclusive properties into a single constraint_setting to avoid bloated code.

I still think exec_settings should be added, but I'll get back to that when I'm actually stuck on it.

[DoDoENT]

Here is an example from BCR's OpenCV module that can serve as strong motivation for what this proposal may want to make easier.

[moroten]

Will it look like below? One observation is that adding a new constraint_value affects the older config_settings, which I think is a non-ideal property because private repositories cannot extend the existing implements_sse to include their own constraint_value(name="special_hw_extension") unless patching @platforms.

constraint_setting(
    name = "sse_setting",
    refined_constraint_values = ["//cpu:x86_64"],
)
constraint_value(name = "sse", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_sse", match_any = [":sse", ":implements_sse2"])
constraint_value(name = "sse2", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_sse2", match_any = [":sse2", ":implements_sse3"])
constraint_value(name = "sse3", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_sse3", match_any = [":sse3", ":implements_ssse3"])
constraint_value(name = "ssse3", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_ssse3", match_any = [":ssse3", ":implements_sse4_1"])
constraint_value(name = "sse4_1", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_sse4_1", match_any = [":sse4_1", ":implements_popcnt"])
constraint_value(name = "popcnt", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_popcnt", match_any = [":popcnt", ":implements_sse4_2"])
constraint_value(name = "sse4_2", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_sse4_2", match_any = [":sse4_2", ":implements_avx"])
constraint_value(name = "avx", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx", match_any = [":avx", ":implements_fp16", ":implements_fma3"])
constraint_value(name = "fp16", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_fp16", match_any = [":fp16", ":implements_avx2"])
constraint_value(name = "fma3", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_fma3", match_any = [":fma3", ":implements_avx2"])
constraint_value(name = "avx2", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx2", match_any = [":avx2", ":implements_avx_512f"])
constraint_value(name = "avx_512f", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx_512f", match_any = [":avx_512f", ":implements_avx512_common"])
constraint_value(name = "avx512_common", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx512_common", match_any = [":avx512_common", ":implements_avx512_knl"])
constraint_value(name = "avx512_knl", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx512_knl", match_any = [":avx512_knl", ":implements_avx512_knm"])
constraint_value(name = "avx512_knm", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx512_knm", match_any = [":avx512_knm"])
constraint_value(name = "avx512_skx", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx512_skx", match_any = [":avx512_skx", ":implements_avx512_cnl", ":implements_avx512_clx", ":implements_avx512_icl"])
constraint_value(name = "avx512_cnl", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx512_cnl", match_any = [":avx512_cnl"])
constraint_value(name = "avx512_clx", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx512_clx", match_any = [":avx512_clx"])
constraint_value(name = "avx512_icl", constraint_setting = ":sse_setting")
config_setting_group(name = "implements_avx512_icl", match_any = [":avx512_icl"])

[fmeum]

I would only add v1, v2 and v3 microarchitecture levels as constraint_values and then all the various special instruction sets would be modeled as config_setting_groupss matching the levels that contain them. If someone needs more fine-grained values, we can always introduce intermediate versions (perhaps someone else has already done so).