Previously, FastISel for WebAssembly wasn't checking the return value of getRegForValue in certain cases, which would generate instructions referencing NoReg. This patch fixes this behavior.
Details
Diff Detail
Event Timeline
test/CodeGen/WebAssembly/noreg.ll | ||
---|---|---|
1 | Portions of this pass are getting called through e.g. the generic FastISel.cpp:1417 and SelectionDAGISel.cpp:1369 for selecting return instructions. | |
11 | Yes, I believe they are necessary. The issue is that when optimization has been turned off in the front-end, instruction can have sufficiently complex operands that fail inside getRegForValue during FastISel, which will return zero. But previously we weren't checking these return values, putting NoReg into the generated instructions and causing problems later. |
test/CodeGen/WebAssembly/noreg.ll | ||
---|---|---|
1 | Hm, I didn't realize that any of this ran when not using fast-isel. In any case we should also add a second RUN line that includes -fast-isel to explicitly get as much of fast-isel as possible. | |
3 | This description doesn't really make sense; the fact that NoReg operands are generated is the bug. Really what is happening is that there are parts that cannot be selected by fast-isel but it doesn't properly bail out. |
test/CodeGen/WebAssembly/noreg.ll | ||
---|---|---|
3 | Oh, probably the corollary to "fix the comment to say what the tested condition and expected result is" would also be to change the name of the test file to something that reflects the tested condition. |
This command line shouldn't result in fast-isel even running, should it?