[PATCH] D80361: [WebAssembly] Convert more lld and MC tests to assembly

[Sam Clegg via Phabricator via llvm-commits]

sbc100 marked 3 inline comments as done.
sbc100 added a comment.

In D80361#2049868 <https://reviews.llvm.org/D80361#2049868>, @tlively wrote:

> What is good documentation to read to become familiar with all the generic assembly directives? I could write a .ll test from scratch by hand, but I don't know the .s format well enough to write an assembly test from scratch. I would like to avoid my workflow becoming 1) write test as .ll then 2) run llc to get .s and commit the output.


I don't know if there is any specific docs for this format.    Its shared a *lot* of code with the gerneric asm parser / printer so a lot of the format matches what you might see in any .s file (e.g. x86).

I'm afraid that the technique of running llc to discover the format is probably the best way to go today.  At least then its guaranteed to be current.    Sorry I don't have a better answer.



================
Comment at: lld/test/wasm/optional-symbol.s:2
+# RUN: llvm-mc -filetype=obj -triple=wasm32-unknown-unknown -o %t.o %s
+# RUN: wasm-ld --export=get_handle %t.o -o %t.wasm
+
----------------
dschuff wrote:
> pre-exsting issue, but should this test have an expectation?
I think its just here to ensure that the __dso_symbol get successfully created by the linker.  I'll look into adding something though.


================
Comment at: lld/test/wasm/signature-mismatch.ll:79
 ; RELOC-NEXT:         Name:            call_ret32
-; RELOC-NEXT:         Flags:           [ VISIBILITY_HIDDEN ]
 ; RELOC-NEXT:         Function:        3
----------------
dschuff wrote:
> is this change in expectation intended?
Its not relevant to the test, and its one less line of boilerplate in the .s file.


================
Comment at: llvm/test/MC/WebAssembly/blockaddress.ll:7
-
- at foo = internal global i8* blockaddress(@bar, %addr), align 4
-
----------------
dschuff wrote:
> do we have any tests that test the lowering of the blockaddress IR instruction?
Thats a good question.  I was in the process of converting these MC tests when I realized they might also be testing codegen by accident. 

Perhaps the best thing to do is to revert all the MC tests here, and consider them separately?   (Since the coverage reduction risk only applies to the MC tests not the lld ones).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80361