Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

@dschuff @sparker-arm

If you want to keep tabs on it, or have any suggestions.

Probably going to a little while before there's anything worth seriously reviewing.

@dschuff

I'm getting close to having a MVP for you to review. But in the meanwhile, I have a question (if you don't know, maybe you'll at least know who does).

I'm working on the instruction selection phase currently. The compatibility layer works pretty well for importing the existing (SelectionDAG) tblgen patterns to work with GISel. So far one of the biggest issues is that my p0 (LLT; pointers in address space 0) aren't getting matched existing patterns expecting an i32/i64 (LLT s32 or s64?). For instance, G_CONSTANT matches to CONST_I32/CONST_I64 when giving a constant s32 or s64, but fails when providing a p0 (e.g. 0 to represent null pointer).

What's the best way to fix this. Do I just have to manually implement select for such operations, or is there a way to tell SelectionDAGCompat to treat p0 as either i32/s32 or i64/s64 depending on the current address size?

Note that regbankselect is already putting them in i32regbank or i64regbank as appropriate, so that's working. Its just isel that isn't matching them.

Yeah, unfortunately I don't know that much about GIsel specifically. This sounds like a good question to bring up on Discourse.

@topperc you might find this interesting.

@dschuff
Alright! I've gotten it into a decent state.

It's obviously not fully complete, but I think its far along enough to warrant a review (does that mean I should un-draft it?). I'm not entirely sure what LLVM's policy is on PR size/completeness, but I get the strong impression the GlobalISel implementation doesn't need to be 100% the first go.

Feature wise, here's a list of major things still missing (to my recollection)

• f16 - need to figure out how to properly legalize/lower the FPEXT and FPTRUNC call
• i128/wide-arithmetic
• Complete SwiftCC support - currently there's some issue somewhere with alloca ptr swifterror
• Bulk memory - need to figure out how to port the CFG triangle over, and figure out the return type on the libcall variant
• Atomics
• SIMD - I have very little understanding of how the vectors fit in across the board, so that might be a job better suited to somebody else
• Error handling
• Intrinsics
• FMAXNUM/FMINNUM (and _IEEE variants?)
• WASM Global (addrspace 1) access
• WASM table operations
• Reference types (funcref, exnref, externref)

Besides those, there are other things that still need adding.

• Alternate instruction mappings for regbanks (so that floating-point loads are lowered directly instead of becoming e.g. i32.load + f32.reinterpret_i32) is one.
• Optimization is another. Luckily I think most of the opts currently missing are builtin GISel combine patterns, they just have to be enabled/configured
• Tests. Currently there are absolutely no new tests. I'm not sure exactly what to test, and in how much depth.

Which of these do you want done before a review, and which do you think should be complete for merging this initial PR.

My main focus was to get this in a functional state as quickly as possible, so there's undoubtedly plenty of room for cleanup. Call lowering in particular needs addressing, as I had to copy & paste private code from elsewhere rather than use the higher-level public API, due to WASM's unique value-stack [no phys reg, no stack spilling].

This is also basically my first time working with significantly with the LLVM codebase (short of that one small PR and issue last month), so I'm learning along the way. There seem to be lots of ways to accomplish certain tasks, so it sometimes gets confusing what the correct/optimal approach is.

I suppose this is a good a time as any to ask, is there still interest in all of this? How far along does this need to get before others will start working with and improving it?

I wonder how much #159880 and the already merged #158269 would do to help me remove the custom patterns for p0.

It just feels like I'm missing something simple to say p0 goes in either I32 or I64 depending on HwMode. Doesn't seem like this new stuff addresses that.