ah right, i had forgotten that.
no worries, I'm probably the right one to be reviewing this; I've thought a lot about linking, even if I didn't write any of this code :D
speaking of which, can you also add the _REL_ relocations to the linking.md doc in tool-conventions?
oh also "WebbAssembly" in the CL title should be "WebAssembly"
Tue, May 26
Thu, May 21
If there's a difference between wouter's clang-format output and heejin's / the bots, it could be that the default clang-format on debian is really old. that's an issue I've seen before.
https://sourceware.org/binutils/docs/as/ is my go-to reference for assembly.
Mon, May 18
Fri, May 15
You know, it's pretty amazing that WebAssemblyISelLowering.cpp is as small as it is.
I guess the existing tests didnt catch this because the pop is still within the same subprogram. Did you see this just at the end of a function, or where?
Thu, May 14
great, still LGTM
Tue, May 12
Mon, May 11
Actually, would it be possible to not ignore throw() but make it an alias for noexcept(true)? Apparently that is the standard behavior in C++17, so it might make more sense to just implement that now rather than just warning all the time and ignoring it. It would also cover most of the cases that exist, so more users wouldn't need to disable the warning.
Wed, May 6
Tue, May 5
So the plan is to support unresolved-symbols and then eventually deprecate and remove this?
Mon, May 4
Wow, did our one external partner test case trigger all of these?
Apr 23 2020
We can definitely still talk about what you are trying to do, and it would probably be useful to have more folks involved. Opening an issue on https://github.com/WebAssembly/tool-conventions/ might be useful since it involves the conventions that LLVM and clang use. If it's specific to the web, then https://groups.google.com/forum/#!forum/emscripten-discuss could be another place (even if you don't plan on using emscripten's JS code).
Apr 20 2020
@jfb thanks for the heads-up.
I replied on the mailing list thread.
Apr 16 2020
LGTM with one nit
Apr 13 2020
If there really are only 32 codes available for all the user targets, then maybe we should just try to get away with only using one.
Apr 9 2020
(I'll bet Call.getCalledFunction() returns nullptr if it's an indirect call)
@yurydelendik is that actually true? Concretely you are proposing that the form of DW_OP_Wasm_location be variadic instead of fixed, right? i.e. it has different fields based on the value of the first field. I don't think there is any precedent for that in DWARF anywhere, is there? e.g. there are different ops for OP_plus and OP_plus_uconst; or OP_call2 and OP_call4 could be just one op with a similar discriminator, but they are not. You could argue that even having OP_Wasm_location as it is (if it didn't need different forms) is inefficient because instead of the discriminator we could just use different ops, and make it smaller.
It just occurred to me, could we just mark the calls as non-inlineable? I assume we won't be running the inliner after this anyway. Or is that a property of the called function and not the callsite?
Anyway this approach seems ok to me too. It seems to me that there are other places we inject calls to runtime functions too; but I guess the others are mostly to imported functions and don't have this problem?
Apr 7 2020
@yurydelendik that would just take care of the encoding, the bigger question would be how to plumb symbol support into DwarfExpression (including the buffering path).
Apr 6 2020
Apr 3 2020
LGTM. I think IsFoo is probably fine even for plurals because it's a common convention as you say.
I guess if you wanted to be ultra-nitpicky-correct you could capitalize it as IsEHPadFunctionsSetUp (i.e. "set up" as 2 words instead of 1 since "setup" is a noun and "set up" is a verb phrase). But it's probably not worth bothering to change.
I'm totally in favor of verbose commit descriptions :D
You can probably just remove the first paragraph.
Mar 31 2020
Mar 26 2020
Mar 25 2020
No I mean alloca as in the LLVM instruction. Just having an address-taken local in C is enough to cause an alloca in the IR.
(FTR, the failure mode is the same assertion in MFI::getFrameBaseLocal() that we saw before)
the IR to reproduce this is trivial but i'm still trying to reduce the debug info in the test. Basically this:
Mar 19 2020
Mar 18 2020
I think the way you have it written here, it means that *all* swiftcc functions will end up with the extra parameters at the wasm level, and direct calls will also have the extra arguments. I think the test should also cover that (not just indirect calls), and I think the calling convention should be documented since it is basically the core of the swift ABI (even if you don't want to consider it stable yet). So at minimum there should be more explanation in the commit message and there should probably be a doc about the Swift ABI in https://github.com/WebAssembly/tool-conventions/ like there is for C.
Thanks; please also update the commit message to match your comment update.
Mar 17 2020
the diff context looks fine to me now, FWIW
Mar 13 2020
I assume there's some kind of ABI doc that says how swiftself and swifterror are supposed to work and be lowered, is there one other than just the langref?
Mar 12 2020
can you please upload this with full context (e.g. diff -U 999 or just use arcanist)?
Mar 9 2020
Yeah, let's just go ahead and land this. I think once this rolls we can enable DWARF with -g by default and start to get more feedback.
Hm, that's too bad. In theory it seems like it ought to be possible to just remove all the debug info from the IR that's attached to functions (i.e. all the debug.declare/debug.values) and the debug metadata that's associated with all functions other than this one, since this is a completely function-local transform that really only depends on there being any CU information at all.
I've also sometimes had good luck with c-reduce to try to reduce it at the C level rather than the IR level. It might be worth a try.
Or maybe we've let this go long enough, and we could just say that we'll have coverage if we do any continuous builds of a reasonable test suite with debug info?
Mar 6 2020
Mar 5 2020
It's probably worth an attempt, and that sounds like the right approach. A crash bug like this is often not too hard to reduce with bugpoint; i.e. you'd start with clang using -emit-llvm to get the IR, and then let bugpoint reduce the IR.
Yeah, this definitely looks like the likely fix. It's the spot where a local gets assigned that doesn't go through getLocalId. It seems to make sense to still allow this merging, as it would reduce the total number of locals. I guess it does mean that the frame base info would be incorrect when that register has the argument's value rather than the frame base's value, but presumably that would be ok, since the frame base should be live anytime a variable on the stack is live.
Mar 4 2020
Feb 28 2020
Feb 21 2020
Feb 14 2020
Yes, that's really all I'm after here.
While I've got your attention, do you have any advice about best practices for debug info tests?
It seems like in this case kind of the minimal thing would be to take an existing small debug info test (which in many cases are clang-generated), switch the debug info version metadata tag to 5 and run it through llc. Or is there some simpler thing?
LGTM assuming removing this is what we want given D74531
Feb 13 2020
Don't remove all custom sections with --strip-ally
Updated, please take a look.
rebase, add comments to test expectations
Feb 11 2020
FWIW this LGTM, especially if this is the same approach used in the other backends.
Feb 5 2020
fixed in rGf5f70d1c8
My bad, sorry about that.
Fixed the nit and added the test for dump-section and remove-section. The clang-format bot seems very confused, but I ran clang-format locally.
- Merge branch 'master' into objcopy-add-remove
- Address comment, add test for dump+remove
Feb 4 2020
The langref says (https://llvm.org/docs/LangRef.html#call-instruction) that the tail call marker implies that the callee does not access allocas from the caller. So it seems like it *should* mean that the backend can depend on this property (that you're checking for here). It also means that the frontend should guarantee it as best it knows how, and optimizations should not introduce it (or remove the attribute if they do?). There are lots of ways to sneak pointers into places (aliasing, going through memory, etc etc) so I'd expect the check in this CL to be brittle.
It doesn't look like there's anything wasm-specific here. Surely this also inhibits tail calling in other backends too? Are frontends suppost to avoid putting 'tail call' in the IR in this case?
Jan 31 2020
- address review comments, clang-format
Jan 30 2020
Rebased against master, and addressed all the comments; please take a look.
- comments, and fix file errors
- dump section before removal
- Merge branch 'master' into objcopy-add-remove
- Update for fixes in previous CL
Jan 29 2020
Relanded with a fix as rGf2af0607000c
I don't have a BE machine to test on, but I'm *pretty* sure it works :)