I was talking to @Vadim Petrochenkov and he suggested reaching out to you about the best way to encode a argument attribute in the MIR. He suggested maybe a boolean flag specifically for this rustc_required_const instead of encoding all attributes.
why do we want this to affect MIR?
I was under the impression
rustc_args_required_const was always a temporary hack — we can achieve the same thing with const generics, so we shouldn't special-case too much to support it
@jakevossen5 You need to access this from outside the function, not from the MIR body (which is the "inside" of the function, so the speak)
@jakevossen5 the most important part is how you can detect this cross-crate. locally you can just look at the HIR, but cross-crate is the hard part, and if you do that right then you'll end up with a query which you can implement locally too (and encoding the cross-crate data would just use the query)
probably a decent way to do it would be like this https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/rmeta/mod.rs#L330
left this comment https://github.com/rust-lang/rust/issues/69282#issuecomment-602130836
How hard would it be to turn
rustc_required_const into real const generics when desugaring to HIR? That would make bjorn3/rustc_codegen_cranelift#666 much easier to implement.
FYI I use the same mechanism as
const operands to inline assembly.
... which means that my code is currently broken since it also assumes that the MIR resolves to a constant...
@bjorn3 Have you tried calling
Yes, I am using
eval_mir_constant. The problem is that for example
_mm256_extract_epi64 is a single function, that is codegened a single time without being specialized on the imm8 argument. However the
simd_extract intrinsic needs to know the value of imm8 at during codegen. With cg_llvm this is not a problem, as it only needs to have a known value after inlining and other optimizations, but clif ir treats it as a real immediate, so you can't pass a value that will be known after optimizations.
Ah I see. Does
#[inline(always)] force MIR inlining?
No, unfortunately not.
wait how does that even work
simd_extract being used by
_mm256_extract_epi64 with only the latter having
because that's scary, intrinsics should be correctly annotated
IIRC I was told this wouldn't be allowed to happen
so we stabilized functions like this?!
@Amanieu @bjorn3 the only correct thing to do, IMO, would be to force
#[rustc_args_required_const(...)] to be applied to an intrinsic, and to make all of the users of the attribute intrinsics
note that your inline assembly should be fine, and so should intrinsics
it's only functions where it doesn't make much sense
this is all because we have forsaken platform-intrinsics
which was for silly concerns such as optimizing for adding intrinsics one by one
as opposed to treating it like a data entry thing
Maybe once we have const generics we could make
#[rustc_args_required_const] just desugar to const generics.
try not to assume that, though
intrinsics and inline assembly are fine, because they're builtin so we can attribute arbitrary semantics to them
anyway I have to deal with another mess atm, and then probably just sleep
@bjorn3 How about forcing MIR inlining just for functions marked
#[rustc_args_required_const(...)]? Since this attribute is only used in stdarch, we should be able to avoid all the existing issues with MIR inlining.
Either than or monomorphizing such functions as you would with const generics. I don't really see any other solutions.
the real solution is to get rid of it on functions with bodies
how come stdarch is still not yet in tree? what a disaster
anyway, opened https://github.com/rust-lang/rust/issues/70271
Thank you, I will look into this!
Does this change how I should do my implementation?