Chris Fallin

Hi @pepyakin -- sorry for the delayed response here. I think introducing `RegImm` is actually exactly what we want here: it models the possibilities given by the instruction in the...

I'm doing some issue gardening here and I believe we have done *most* of the above by now: we have conditional move-based mitigations on heap accesses, table accesses, and branch...

> How fast is this code? How much would the increase in compile time for this be? I haven't measured yet but I will soon. There are some optimizations I...

I agree that sign-extension makes the most sense here. There is actually an equivalent issue with `iconst.i128`; I just verified now that on x86-64 and aarch64, `iconst.i128 -1` produces a...

I think this general approach is sound -- thanks for the early-feedback pass @avanhatt! One general thought: I have a sense that internal-extractors-as-macro-expansion should not be special-cased, in the long...

cc @abrown @jlb6740

Thanks for the report. Did this CLIF come from Wasmtime or some other frontend? (I ask because we try to support Wasmtime's use of Cranelift on aarch64-apple-darwin but the use...

> I want to know Why not choose to support x86-32? What are the considerations? Hi @MichealZwen -- we'd love to do so; the only real issue is time and...

Ah, yes, I have just realized that this issue is on the Lucet repo and not Cranelift (my mistake, unified notifications inbox...); please interpret my comments above in the context...

Actually that would be the ideal design: from first principles one would expect "with immediate" variants of 128-bit ops to carry 128-bit (16-byte) immediates. However we can't carry that inline...