This handles all load/store operations that WebAssembly defines, and handles those necessary for C++ such as i1. I left a FIXME for outstanding features which aren't required for now.
Details
Diff Detail
Event Timeline
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp | ||
---|---|---|
94 | Is there a reason why OpcodeName has to be a member function? | |
103 | Ditto? | |
103 | And ditto here? Having this be a standalone function nicely emphasizes that it's just a pure function from APFloat to string. | |
lib/Target/WebAssembly/WebAssemblyInstrMemory.td | ||
33 | Nit: Why the trailing underscore in the name? | |
62 | I'm ok with expanding things out like this, but several other things in the WebAssembly tablegen files are aggressively factored out into multiclasses. Is there a reason these aren't multiclasses too? | |
71 | Please add a comment mentioning that WebAssembly's operand order is the opposite of SelectionDAG's operand order here. |
- AsmPrinter: back to static functions.
- Note on store operand order.
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp | ||
---|---|---|
94 | Name lookup was sad because I have two toString methods, but I changed the Type version to take in hasAddr64 and moved everything back to static, so it's all good. | |
lib/Target/WebAssembly/WebAssemblyInstrMemory.td | ||
33 | I'm playing tricks with the name printing: it truncates out the last underscore and everything after it, so this prints as load_i32. We can come up with another scheme (maybe pass in a string), but this was pretty simple to start with. | |
62 | Maybe I'm lacking imagination: InstrFormats-style multiclasses would only be used once each here? There's one load per type, and the #_I32 concatenation has to be textual IIUC. Similarly for extending loads? Or maybe tablegen has extra tricks I don't know :-) I was thinking that HasAddr64 should be done with a multiclass for Ptr:$addr and require, but I figure this should be a separate patch. |
Is there a reason why OpcodeName has to be a member function?