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

[Sam Clegg via llvm-commits]

sbc100 wrote:

> The short answer is that's what the [Lime1 CPU calls it](https://github.com/WebAssembly/tool-conventions/blob/main/Lime.md#lime1) 😄 .
> 
> > Can you explain why you want call-indirect-overlong in lime1? Is it because you want to be able to link files compiles with multi-table? i.e. do you want/expect type relocations at every call_indirect site? If so then perhaps a better name might be call-indirect-relocatable? Or maybe even multi-table-compatible? Sorry for the bikesheding and this late stage..
> 
> I included call-indirect-overlong in my original Lime1 proposal because of the simplicity of it. I expected it's easy for mvp-level engines to add support for it. And the more engines support it, the fewer users will see obscure binary decoding errors in cases where a toolchain tries to use an overlong and an engine doesn't recognize it.
> 
> Concerning naming, from Lime1's perspective, call-indirect-overlong is just a language feature. It's not inherently _for_ call-indirect relocations or multi-table separate compilation strategies. Engines should just accept `call_indirect` instructions with overlongs, so it's called "call-indirect-overlong". Toolchains can then use that behavior whenever they have a need for it.

I see, so in practice the effect on LLVM is that you get a relocation at each call_indirect site but we don't need this relocation of the wide encoding for any particular reason. 

It seems like a lot of steps and complexity just to force some binary decoders to support an otherwise unused feature.. but you think its worth the effort?

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