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