| Issue |
178139
|
| Summary |
[lld][Webassembly] Question : How can we educate lldWasm about the Incremental compilation use-case ?
|
| Labels |
lld
|
| Assignees |
|
| Reporter |
anutosh491
|
> The options / option parsing is the global state.
Now that we're discussing setting/ options in the global state, there is another important problem I have to point out
cc @aheejin
Clang-repl's wasm backend that makes use of [lldWasm](https://github.com/llvm/llvm-project/blob/3bab75245a2bbbec36206f7e0c569c17a1a487e6/clang/lib/Interpreter/Wasm.cpp#L120-L138) to generate corresponding shared wasm modules (incr_module_x.wasm) from the "incremental" LLVM IR modules produced per input (input_line_x)
Now as asked about clang-repl's architecture, as shown in the [design docs](https://clang.llvm.org/docs/ClangRepl.html#clang-repl-basic-data-flow), we use clang as the frontend.
Which means if any options/llvm args are passed through the command line or while setting the compiler builder (or anyhow reach the cc1 command) they would prevail just like clang !!! There should not be any difference.
But, I notice a catch here!!!! When we are running a clang-repl instance, we want the same set of functionality for all inputs being passed by the user. Which means, any option passed from the top should prevail throughout.
But what we notice while running clang-repl in the browser is, **cell 1 would respect the options but cell 2 won't**.
And this is because of this line here.
https://github.com/llvm/llvm-project/blob/3bab75245a2bbbec36206f7e0c569c17a1a487e6/lld/wasm/Driver.cpp#L1315
Basically the driver assumes it to be a "standard/traditional" compilation where we can afford losing the compiler based options and only focus on the linker ones. But the driver is not educated yet for understanding "incremental" compilation.
The [commit](https://github.com/llvm/llvm-project/commit/f2efb5742cc9f74ad73987760651e3d23894a416) introducing this says "In lit tests, we run each LLD invocation twice (LLD_IN_TEST=2), without shutting down the process in-between. This ensures a full cleanup is properly done between runs."
So this points out a cleanup between "two separate runs" but our "run" involves two separate inputs but within a single run 😅
Hence for now we need to take a not so good route where we need to parse the mllvm args and other options every time before parsing/executing an input (check comment here : https://github.com/llvm/llvm-project/pull/132670#discussion_r2712343394)
But there should be a way in which we should be able to negate the hard reset on options that is being done. Can you think of an approach for the same (I don't know, possibly a linker arg like `--incremental` which promotes not clearing out all options ?)
tagging @sbc100 @MaskRay too who I think look after lldwasm.
_Originally posted by @anutosh491 in https://github.com/llvm/llvm-project/issues/146343#issuecomment-3783700083_
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
