`-Calign-loops=1` support in `rustc`

[ojeda]

i.e. the equivalent of -falign-loops=1 (GCC, Clang).

[ojeda]

@rustbot label I-rust-for-linux

[folkertdev]

This behavior can already be accessed with e.g. -Cllvm-args="--align-loops=32", see https://godbolt.org/z/eEc1oP7MY. When you change the alignment, the p2align directives on line 44 and 72 change their alignment to match.

So I think rust does not need custom support for this flag?

[ojeda]

Thanks, that is good, but what about other backends, e.g. GCC? This flag may not be commonly used, but should we leave it up to per-backend flags?

[folkertdev]

well with this flag you'd always be passing a flag on to the backend: rustc itself does not know what loops are hot or cold (in this it is different from e.g. the function alignment, where we can explicitly set the alignment of each function).

By making it a rust flag, you'd have to guarantee consistent behavior between targets (I would think, anyway). Can we guarantee that gcc and clang do the same thing here (in the sense that the rust specification could describe their behavior)? And e.g. cranelift does not support loop alignment at all as far as I can tell.

Making this the responsibility of the backend, via some per-backend configuration flag seems like by far the simplest option. But if there really is a pressing need maybe something more is possible? I don't know, and don't have any authority here.

[ojeda]

well with this flag you'd always be passing a flag on to the backend:

What I meant was that projects would need to use those per-backend flags themselves. That is, every project would need to repeat that logic on their side (for flags that are supported by e.g. both GCC and Clang). That may be fine, since projects needing this kind of flag can probably figure it out and there may not be many.

By making it a rust flag, you'd have to guarantee consistent behavior between targets (I would think, anyway).

I don't know what is the policy here -- do flags need to require consistent behavior? Could the documentation avoid specifying details where they may not be guaranteed? Or, could it state that it behaves like -falign-loops for the GCC and Clang backends? For Cranelift etc., it could perhaps be an error to apply it to backends for which it does not make sense, or it could be defined as not having an effect.

Making this the responsibility of the backend, via some per-backend configuration flag seems like by far the simplest option.

If those per-backend flags are stable, then that would be good enough for us, yeah. In that case, it may be a good idea to document these.

Thanks!