[clang] [lld] [llvm] [WebAssembly] Define call-indirect-overlong and bulk-memory-opt features (PR #117087)

[Dan Gohman via cfe-commits]

sunfishcode wrote:

> I do think its reasonable for all those decoders to support overlong LEBs. But I think I don't see the advantage that adding this new pseudo feature offers. Wouldn't it be simpler to simply not add it?

I see it more as exposing existing complexity, rather than creating new complexity. It's already surprising that enabling the reference-types feature changes how LLVM isel and MC handle indirect calls, and changes the encoding for call indirects,  when no actual reference types are involved. This new call-indirect-overlongs flag just exposes that behavior change as a distinct feature.

Adding call-indirect-overlongs to Lime1 simplifies plausible scenarios. Perhaps some users will run "generic" code in their Lime1-supporting engines, in cases where that works. Perhaps some users will use Lime1 and compile some things with reference-types enabled (even when it doesn't need to be, because Makefiles are complex). Perhaps a future Lime2 will include exception-handling, and then include more of reference-types, in order to support `exnref`. If Lime1 includes call-indirect-overlongs now, then none of these scenarios risks having indirect call encoding changes popping up and causing confusing binary decoder errors in the middle of things.

https://github.com/llvm/llvm-project/pull/117087