[llvm] [WebAssembly] Implement GlobalISel (PR #157161)

[Derek Schuff via llvm-commits]

dschuff wrote:

> That all makes sense.
> 
> True, maintaining this will require extra effort, and the short or even mid-term benefits are hazy at best. Combiners don't seem 100% up-to-par yet, so codegen quality is likely to be a little worse, rather than the ideal better. But given time that can be fixed (as either work on this particular backend/target or as GlobalISel matures in general). Improved code maintainability was another hypothetical, and I personally do feel that GlobalISel is nicer to work with than SelectionDAG, and more robust in certain ways; then again, I'm biased (having at this point spent more time learning the new system than the old one). However that point is also kind of moot if we still have to maintain this in addition to the existing system.

So far no backend has managed to fully replace an SDISel-based pipeline with a GISel pipeline, so my default assumption is that it will take a long time. Part of the reason is that it's a moving target, with most development still happening on SDISel. But also, compilers are critical infrastructure and testing upstream is never as comprehensive as you'd want it to be, so moving defaults is hugely risky and has to be done carefully. Once we have something upstream that can be enabled for testing and we think is close to mature enough to switch to, we'll want to start testing with a lot of real users. (This is where it helps to be part of a large organization that's already building huge codebases, and to have lots of contacts with users). But that process frequently raises issues for big migrations and it can't be rushed.

It does help that our backend is simpler than most. But we are getting more improvements as we speak, and I don't want to slow or stop that progress while we work on new infrastructure. 

> 
> However, at the same time, if we do want to reap the benefits long-term, I see little value in waiting. The sooner more backends try adopting it, the more we can expose and work towards fixing the remaining shortcomings (mainly missing optimization passes) of GlobalISel to the benefit of all. Also, one way or another this is going to take a while just to get the ball rolling. We need to time to build it, and to attract both testers and contributors. The sooner the better.
> 
> Then again, without a clear commitment to slowly, steadily shift efforts this way, it WILL end up deadweight, as there won't be enough users nor maintainers to justify it. Something of a chicken-or-the-egg, but I think we leave that as a secondary concern. First is getting a usable base to build upon and implementation to test (i.e. what I/we are doing here).

"sooner the better" maybe true if "we" means all the backends together, but less true if you have just a small number of people and are unable to unilaterally drive much progress on shared infrastructure. As you say, it's sort of a chicken-and-egg/collective action problem. But even more well-resourced teams have lots of priorities and near-term benefits they need to deliver, so it can be hard to do this kind of thing, and this history of LLVM is full of unfinished migrations.

If we are unable to contribute meaningfully to the shared infrastructure, then the optimal solution (for us, not for the community) is to shift focus right when the critical mass of the community shifts, rather than sooner.

But one nice thing about open source is that it's (sometimes) easy to get more contributor effort for this kind of thing.

> 
> I think targeting FastISel first sounds like a good intermediate step. I had been focusing primarily on replacing SelectionDAG, but considering the narrower feature set and lesser optimizations, it's probably a closer match in this PR's current state, and would be easier to quietly swap in without too much fuss. I'll take a look and see what's still missing to bring it up to FastISel standards.

FastISel actually is pretty lacking in terms of features (both in terms of wasm features like post-MVP instructions, and also in terms of less-used LLVM IR features. So it shouldn't be too hard to match it. I do think we should do a bit of performance testing to ensure the compile time regression isn't too much. I haven't done much compile time testing before; I can check internally to see if we can measure this with our internal build system. It might also be worth trying to set up CTMark for wasm. I assume there will be at least some unavoidable regression. One way to help mitigate it might be to reduce the number of times we need to fall back to SDISel (which of course is slow) compared to FastISel. I haven't looked recently how often this happens, but there are some statistics we can look at for that.


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