Add support for ?, DUP, and string initializers, as well as MASM syntax for named data locations.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/MC/MCParser/MasmParser.cpp | ||
---|---|---|
2889 | What does ml do with BYTE 2, 4, 6, 8, BYTE 2, 4, 6, 8, ? Does it really error out? |
llvm/lib/MC/MCParser/MasmParser.cpp | ||
---|---|---|
2889 | Believe it or not, yes! test.asm(2) : error A2206:missing operator in expression |
llvm/lib/MC/MCParser/MasmParser.cpp | ||
---|---|---|
3018 | Is there no more efficient way to express this internally? If you 1000000 dup (2), do we have to write out 1M 2s? |
llvm/lib/MC/MCParser/MasmParser.cpp | ||
---|---|---|
3018 | We could optimize the case of 1000000 dup (2) with a fill-type instruction, but I'm not sure how we would handle (e.g.) 500000 dup (2,3). Also, this is data-initialization logic, so either way the actual binary is going to contain 1M literal copies. Do you think it's worth special-casing the single-value handling internally anyway? |
llvm/lib/MC/MCParser/MasmParser.cpp | ||
---|---|---|
3018 | as-is is fine for now |
llvm/lib/MC/MCParser/MasmParser.cpp | ||
---|---|---|
3018 | Just a note for the future. Currently this means we actually make 1M copies of the APInt representing a real with value 2 in memory while compiling, and don't let go until we've processed the entire initializer list. There are three cases here:
Case 1 could be optimized by using Fill logic. Case 3 is more of a problem, though. Arbitrarily nested duplications get hard unless you expand them in place, as the current code does... or unless you parse them into a specialized tree structure, and expand it back to actual values only as needed. All of this is complicated by the fact that once STRUCT support is in place, we do need to be able to parse initializers and hold them in memory, not just emit them immediately. The ideal solution would probably be a tree-based intermediate representation for initializers, with duplication nodes representing "X DUP (<child>)". It's probably worth coming back to this eventually, but we'll leave it as-is for now. |
It looks like this broke the Windows LLDB Buildbot:
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/14117
Already reverted in http://reviews.llvm.org/rG9fe769a961dc - apologies, I lost track and thought we'd moved to supporting C++17 code in the codebase. The version here included use of an initializer in an if-statement.
This will be landed again in another commit.
clang-format: please reformat the code