This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Use named operands to identify loads and stores
ClosedPublic

Authored by tlively on Mar 5 2019, 5:11 PM.

Details

Summary

Uses the named operands tablegen feature to look up the indices of
offset, address, and p2align operands for all load and store
instructions. This replaces brittle, incorrect logic for identifying
loads and store when eliminating frame indices, which previously
crashed on bulk-memory ops. It also cleans up the SetP2Alignment pass.

Event Timeline

tlively created this revision.Mar 5 2019, 5:11 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 5 2019, 5:11 PM
tlively edited the summary of this revision. (Show Details)Mar 5 2019, 5:18 PM
tlively edited the summary of this revision. (Show Details)Mar 5 2019, 5:59 PM
tlively updated this revision to Diff 189434.Mar 5 2019, 6:01 PM
  • Fix SIMD, restore SIMD tests

Nice! I'm learning more tablegen stuff everytime I see your CL 👍I have a few questions:

llvm/lib/Target/WebAssembly/WebAssemblyRegisterInfo.cpp
74

Nit: how about making it a variable as you did for OffsetOperandNum below, like

unsigned AddrOperandNum = WebAssembly::getNamedOperandIdx(
          MI.getOpcode(), WebAssembly::OpName::addr));
if (AddrOperandNum == FIOperandNum) {
  ...
86

While this is a lot more general and better than the previous code and the fix looks correct, I can't find any bulk memory instructions in its td file that has addr operands. I don't think the bulk memory test cases enter this if block. Is that intended?

llvm/lib/Target/WebAssembly/WebAssemblySetP2AlignOperands.cpp
94

Why not changed? I see the previous code didn't even touch Changed, but aren't we supposed set it to true when if (P2AlignOpNum != -1) holds?

llvm/test/CodeGen/WebAssembly/bulk-memory.ll
147
  • This sentence sounds like __stack_pointer global itself is bumped to a new location, which actually happens in non-leaf functions. But here we only read it to compute the frame index and don't modify __stack_pointer itself..?
  • "in non-leaf function it must be 16-byte aligned, and there is no special case for leaf functions.": Why is it 16 bytes aligned and why is there no special case for leaf functions?
tlively updated this revision to Diff 189649.Mar 6 2019, 8:51 PM
tlively marked 7 inline comments as done.
  • Address comments
tlively added inline comments.Mar 7 2019, 10:04 AM
llvm/lib/Target/WebAssembly/WebAssemblyRegisterInfo.cpp
74

Good idea, will do.

86

Very much intended! The previous errors were due to bulk memory operations were entering this block, which tried to extract Offset operands that did not exist. Now they do not enter this block, which fixes the error.

llvm/lib/Target/WebAssembly/WebAssemblySetP2AlignOperands.cpp
94

I had this question too, but I did not know the full context of what this return value means and how it is used, so I wanted to be conservative and not change the behavior of the code. It looks like setting Changed to true if we call rewriteP2Align doesn't break anything, so we can go with that.

llvm/test/CodeGen/WebAssembly/bulk-memory.ll
147

Updated to reflect my findings from investigating TransientStackAlignment.

aheejin accepted this revision.Mar 7 2019, 10:26 AM

LGTM w/ a comment question.

llvm/test/CodeGen/WebAssembly/bulk-memory.ll
147

The comment still says "stack_pointer is bumped". What I meant was __stack_pointer is NOT bumped, i.e., there's no global.set __stack_pointer in the generated code. Isn't __stack_pointer here just used to compute the frame index?

This revision is now accepted and ready to land.Mar 7 2019, 10:26 AM
dschuff added inline comments.Mar 7 2019, 11:08 AM
llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.cpp
30

do you need to #undef GET_INSTRINFO_CTOR_DTOR before you include the .inc file again?
edit: also above.

tlively marked 2 inline comments as done.Mar 7 2019, 11:12 AM
tlively added inline comments.
llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.cpp
30

No, the undef is taken care of inside the included file. This is a common pattern for including all TableGen files.

llvm/test/CodeGen/WebAssembly/bulk-memory.ll
147

There are two "stack pointers" in play here. The stack pointer that gets bumped is LLVM's idea of a stack pointer, which is subject to StackAlignment and TransientStackAlignment and is used as the base address for the offsets of locals. The global __stack_pointer that participates in the WebAssembly ABI does not get bumped because we're using the red zone, but that is an invention of the WebAssembly backend that the rest of LLVM is not aware of.

I guess I can make this less confusing by saying "The stack pointer is bumped" instead of "__stack_pointer is bumped". Does that seem reasonable to you?

aheejin added inline comments.Mar 7 2019, 11:18 AM
llvm/test/CodeGen/WebAssembly/bulk-memory.ll
147

Yeah that sounds clearer.

This revision was automatically updated to reflect the committed changes.