Experimental supports cfg

[pinkforest]

Re:

• AVX512-IFMA & AVX10 status #635
• AVX512 code will need to change to handle the whole AVX10 business #693

p.s. how do we implement the opt-in given we have declared backend details as implementation detail.

feature will not do as it poses problems of a) relaying across dependency chain b) not having top-level binary in control

Same as #414 we could use cfg for this - I propose:

cfg(curve25519_dalek_unstable = "avx512")

Which will in turn support for unstable AVX512 through nightly opt-in unstables basis.

[tarcieri]

I would suggest using the existing curve25519_dalek_backendcfg rather than adding yet another one

[pinkforest]

Problem is this is more like sub-configuration and it conflates configuration between stable and unstable configuration.

By denoting explicitly that it's unstable, it avoids the confusion of opting into something that is not entirely stable.

e.g. curve25519_dalek_backend is mostly for stable backend configuration and is provided for solely as "override"

Also backend is more backend class and not explicit backend, e.g. "simd" can mean anything in between those stable-only backends.

Additionally providing override to sub-backend gets confusing when it's supposed to be only override and not opt-in cfg.

[tarcieri]

Having two different cfg options for the backend reintroduces the problem that they can both be set in conflicting states, which was the whole reason we moved away from features in the first place.

I think we already have all the cfg options we need and the main thing we need to do at this point is not automatically enable nightly-only features.

[pinkforest]

The cfg conflict happens even today, it is perfectly possible to set two cfg values stuffed into same key -

However we guard and test that in build script just like we would guard the opt-in which is different to override.

Adding it under _backend will complicate the gating and will pollute unstable configuration where it has = "simd"

Logically speaking if we have curve25519_dalek_backend = "simd" and then we have "avx512" it will be confusing?

When somebody writes --cfg curve25519_dalek_backend="simd" --cfg curve25519_dalek_backend="avx512"

It gets confusing right? because the above would work .. and confusingly people might confuse it as stable backend

We could say --cfg curve25519_dalek_backend="unstable_avx512" perhaps but still confusing (less though) IMO

[tarcieri]

Your example would be caught by the compiler, as opposed to requiring logic at every backend selection site.

I very strongly believe we should not (re)introduce backend selection knobs that duplicate/conflict with each other.

[pinkforest]

The current backend knobs are overrides and it does not guarantee selection though.

We can settle with backend="unstable_avx512" and at least the value denotes the override into unstable sub-backend.

btw compiler doesn't mind duplicate --cfg values and it's something I had to address earlier

[tarcieri]

Regardless, the point is not to have logic in backend selection code all over the place that has to handle potentially conflicting user inputs.

That would be a major regression over where we are now.

[pinkforest]

Wanna comment on having the unstable_ in the value to denote it's unstable-ness? That would allow it in one cfg.

[tarcieri]

That seems better than two potentially conflicting attributes

[pinkforest]

Cool great let's do that

EDIT: Another could have been curve25519_dalek_backend = "simd_unstable_avx512" but it's longer w/o value