Ah, it seems the reason I didn't see this is that I wasn't using -flax-vector-conversions=none. Thanks for fixing this!

I've now opened https://github.com/WebAssembly/wasi-sdk/pull/151/ to remove the --no-threads from wasi-sdk, which was a workaround for an old bug that has long been fixed.

• Update clang/test/CodeGen/builtins-wasm.c.

• Reorganize the code a little so that we don't have to call mark multiple times.
• Fix a bug where we weren't considering calls from constructors as keeping other constructors live.
• Add a few more tests.

In D85062#2188643, @sbc100 wrote:

To be clear this change only relates to object files at are part of ar archives and are not part of the link? Perhaps mention that in the PR title/description.

Address review feedback.

• Rename -emscripten-pic to -experimental-pic
• Change the warning text to say "not stable" rather than "not yet implemented"

This change looks fine to me, though if you wanted to minimize the amount of code being emitted by the linker, another option would be to look into whether LLVM's FixFunctionBitcasts could handle this -- there should be a bitcast in the llvm.global_ctors array.

Landed in 66042959590d6db9d2a12803a16476d4e3508f3f.

• Address review feedback
• Mark callCtors live in the MarkLive pass rather than in the Writer pass.

Run clang-format and fix lint warnings.

Use the return value of handleUndefined instead of doing a separate lookup, which avoids a redundant lookup and handles LazySymbols properly.

I apologize again for the major delay. I've now updated the patch and addressed all of your comments.

• Add tests for redeclaration behavior
• Remove disabled tests (previously marked with FIXMEs)
• Made the mismatch warning more informative.

Looks good to me.

In D70500#1999268, @bernhard wrote:

It's for users who want smaller wasm binaries. It's not currently documented, though yes, it would be nice to document it.

But how would a user even end up with wasm-opt in the same directory of clang binaries?

In D70500#1998994, @bernhard wrote:

Are there plans to offer a way to disable this behavior (or have it optional in the first place)?
We'd like to run some custom processing between wasm-ld and wasm-opt which can't happen after the latter due to some of its one-way destructive optimizations (i.e. memory-packing or simplify-globals passes).
The only way now is to tell our users to place wasm-opt somewhere where clang can't find it. Or instead of using one clang super-command to manually call -cc1 and wasm-ld separately which is disappointing.

Also, is it even common to place wasm-opt next to the clang executable? Who is this for? Is this documented?

This addresses the review feedback from earlier. To answer this question:

Rebase, update, add a test, and add basic error reporting.

Looks good! I don't have anything to add beyond Thomas' review comments.

Is looks possible that the test failure was due to an unrelated commit 210f40fe9a30212396311d265904b2d73859c53d. If so, it's possible it's fixed as of 74ab5d98d07f0b0226f45ccca8df6a450d52fb7b.

On some 32-bit x86 hosts, particularly those that use x87 arithmetic, loading and storing with floating-point types can change the NaN bit pattern. To preserve the bit pattern reliably, MCOperand should represent floating-point immediates by representing the bits in int32_t for 32-bit and int64_t for 64-bit. Codegen and MC don't usually look at the value, but where they do need to interpret it as a floating-point value, they can reinterpret the bits on demand.

Cool, LGTM, with optional suggestion for signed char below:

Very cool, thanks for putting this together!

Instead of creating a new LLVM-IR-level attribute here, could you have clang translate the attribute to "wasm-export-name", to keep the LLVM-IR level simpler?

The commit description says "not ordered to group destructors with common associated objects" but it looks this patch is doing grouping by associated object. Is that intentional?

• Add a comment.
• Add a test of two destructors with different priorities and the same associated object.

Looks good, with the clang-format lint fixed :-).

LGTM!

@sbc100 Friendly ping :-).

Address review feedback.

I apologize for the extraordinary delays here; at long last, I've now addressed your feedback.

To support a transition to the new system, temporarily define a __main_void alias for no-argument main. This allows libc to detect whether it's calling old-style or new-style main and do the right thing.

This updates the main vs __main_argc_argv patch so that it doesn't apply to Emscripten targets, following the discussion in https://github.com/WebAssembly/tool-conventions/pull/134.

In D70500#1759831, @ilya-biryukov wrote:

I'm not an expert in driver code and how it should behave, but being consistent with how other tools are found definitely looks much better than special-casing a single tool.
Unless there are reasons why wasm-opt should be special, why not use the mechanism used by all other tools?

I've done some more experimenting with this, and it turns out not to work very well, because calls to these functions get generated after LTO runs, so I'll abandon this.

I've now posted https://reviews.llvm.org/D70677 which should fix the test failure when LLVM_APPEND_VC_REV=NO is set.

In D70500#1757735, @thakis wrote:

Please don't add code to the driver that runs programs off PATH. Nothing else does this.

In D70500#1756011, @dschuff wrote:

WRT the LTO directory name, there's theoretically the danger that someone (e.g. emscripten) could be doing a rolling release of the compiler and get invalidated within a major revision.

Do you think that setting this attribute should also prevent GC?

It appears this doesn't handle exporting an imported function yet, which is fine for now, but it would be good to issue a warning, because wasm itself is capable of representing this:

void aaa(void) __attribute__((import_module("imp"), import_name("foo"), export_name("bar")));

Don't run wasm-opt with -O0.

Use PATH instead of WASM_OPT to find wasm-opt.

In D70515#1754288, @sbc100 wrote:

Does this need to be wasm global? Or can it just be regular data symbol like globalBase? i.e. do we want fast access to it without a load?

In D70500#1754012, @sbc100 wrote:

On I just remember why this is probably a bad idea. llvm bitcode is not designed to be stable, unlike object files, so its probably not a good idea to encourage the distributing of bitcode files in SDKs and such.

This kind of thing ought to have helped code like

extern int A[];

Would it be better to do this check in LLVM, in the backend, with a report_fatal_error?

In D66983#1651981, @craig.topper wrote:

DAG combine is supposed to check with TargetLowering::isShuffleMaskLegal.

In D66978#1652070, @tlively wrote:

Generally LGTM, although the tests might be more readable if you pass -wasm-disable-explicit-locals and -wasm-keep-registers as well. It's also concerning that no one noticed this issue before. Do you know why other targets may not have run into it?

• Use -wasm-disable-explicit-locals -wasm-keep-registers to make the test more readable

In D66983#1651977, @dschuff wrote:

Oh, interesting I didn't notice that those are implementations of the target-specific intrinsics. I wonder if they do that so they can implement the intrinsics on hardware that doesn't support the corresponding instruction? In a situation other than that I think I'd be surprised if I used a builtin for a particular instruction and got something else.

Can you say what leads wasm users to maintain such an expectation when, for example, ARM users and x86 users don't?

In D66968#1651483, @sbc100 wrote:

I'm curious why a user would want to use WASM_SYMBOL_NO_STRIP if it doesn't export the symbol? Maybe for post-linker to do stuff perhaps?

Include the basic test case.

Abandoning in favor of https://reviews.llvm.org/D66968.

https://reviews.llvm.org/D66968 is now a patch implementing the lld side of this.

"memory" is now a de-facto standard. We may still be able to change it, but we'll now need a transition plan.

I have a slight preference for landing this change too.

x86 uses address spaces starting at 256 and counting up for its architecture-specific address spaces. The docs say "Address spaces 1-255 are currently reserved for user-defined code." so we should consider using 256 here.

This allows for us to fall back from arch-specific to generic headers as needed. The same can be true of libraries. Not all libraries contains compiled code. .so files can also be linker scripts that reference other libraries in which case they can be arch-neutral.