[PATCH] D59007: [WebAssembly] Use named operands to identify loads and stores

[Heejin Ahn via Phabricator via llvm-commits]

aheejin added inline comments.


================
Comment at: llvm/test/CodeGen/WebAssembly/bulk-memory.ll:147
+; 10 because in non-leaf function it must be 16-byte aligned, and
+; there is no special case for leaf functions.
+
----------------
tlively wrote:
> aheejin wrote:
> > tlively wrote:
> > > aheejin wrote:
> > > > - 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?
> > > Updated to reflect my findings from investigating `TransientStackAlignment`.
> > 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?
> 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?
Yeah that sounds clearer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59007/new/

https://reviews.llvm.org/D59007