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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
