Can we remove the optional altogether now, and just always do the fixup?

LGTM. In the future it's possible we could need to hold the signatures somewhere other than the AsmPrinter, however we can figure that out later, when it's more clear what the MC AsmParser layer will need.

In D52450#1248681, @tlively wrote:

That's true, except that if the semantics of the LLVM intrinsics were not as strict as the semantics of the WebAssembly instructions, then there would be no way for programmers to access WebAssembly's exact semantics at the source level, which is the whole point of implementing these intrinsics at all.

In D52450#1248586, @tlively wrote:

WebAssembly's handling of +0/-0 *does* match IEEE 754-2018, so these intrinsics (whether target-independent or not) need to be changed to match those semantics as well. I will have to investigate whether the fminnan and fmaxnan ISel DAG nodes are already being used in ways that do not respect these semantics. If they are, we will need new ISel DAG nodes as well.

In D52372#1244158, @aheejin wrote:

1. Is it correct to translate those llvm instructions to saturating versions of wasm instructions? For example, for scalars, we had a patch that implemented the saturating behavior. Don't we need a similar thing for vectors too?

The prompt here is that the LLVM wasm backend will be leaving "experimental" status. That means in about 6 months, it'll be part of an LLVM release. Once that happens, it'll be harder to make changes like this.

In D43211#1241361, @sbc100 wrote:

Woah! This a big step people! Congratulations.

@sbc100 @ncw Can you comment on the status of this issue? Is this still something we want to fix before we consider the basic ABI to be basically stable?

https://reviews.llvm.org/D50568 is now fixed!

On one hand, clang-format -style=LLVM really isn't the one exclusive formatting style of LLVM. CodingStandards.rst repeatedly emphasizes this. When we're working in LLVM outside of wasm-specific code, we need to respect the existing code formatting which isn't always clang-formatted, or locally reformat it as needed when making changes, so it's not a bad idea for us to get used to working that way anyway. And we accept patches that aren't clang-formatted.

I guess I don't have a strong opinion here. The code is already pretty close to clang-format's interpretation of LLVM style, so looking at the actual diffs you're right that it doesn't seem to be a big change. Changes like those in WebAssemblyLowerBrUnless.cpp are a little unfortunate, but tolerable.

The LLVM coding standards say "we explicitly do not want patches that do large-scale reformatting of existing code". They suggest that reformatting should be done to address specific readability issues or to prepare an area for subsequent changes.

In D50277#1210237, @aheejin wrote:

We discussed how to implement fences here, and I think the general consensus was even though it may not be strictly necessary to emit atomicrmw for some cases, it can be user friendly and also might help support legacy builtins like __sync_synchronize(). And IMHO it is a single instruction anyway and fences are generally expected to be expensive, so no significant harm will be done. Does anyone have more concerns on this? If not, can we land this?

This looks ok to land now.

Is this related to the issue reported in the thread here?

First, I apologize, I'm not sure how I lost track of this patch and didn't see the pings.

https://reviews.llvm.org/D40526 has now landed. Is there anything else we should do before leaving "experimental" status?

In D49517#1172783, @sbc100 wrote:

Interesting, so you are proposing delaying the error until link time but still producing a valid wasm binary?

In D49194#1172051, @jfb wrote:

I have a talk for you! https://youtu.be/IB57wIf9W1k?t=52m20s
I talk about volatile in a few places, but 52m20s is the main one. Basically I'm advocating for something similar to the weird MSVC x86 volatile behavior because some users write code like a loop which updates a volatile variable which another thread reads, and expect it to stay in the loop (not hoisted out). Lowering to regular load / store breaks the guarantee that volatiles effects touch the variable's bytes once per source event. Such user code should really use atomic, but we don't need to be pedants about it.

In D49194#1170428, @jfb wrote:

In D49194#1170425, @sunfish wrote:

For the record, I'm opposed to having the WebAssembly backend translate asm volatile(""::: "memory") differently from other targets in LLVM or GCC, which to my knowledge always translate it to a no-op, even on platforms with hardware fence instructions.

I think it should lower and not error out, and thought should be put into what it should lower to. No-op seems fine to me, but I'd like to hear a rationale.

For the record, I'm opposed to having the WebAssembly backend translate asm volatile(""::: "memory") differently from other targets in LLVM or GCC, which to my knowledge always translate it to a no-op, even on platforms with hardware fence instructions.

Ah, that's useful context, thanks. That'd be good to mention in the commit message and/or comments somewhere. Also, please add a testcase which approximates that use case.

Not all types are valid to cast to all other types. But beyond that, normal native platforms don't insert non-trivial casts in such situations, so even in many cases where it's valid to cast, it doesn't seem like programmers could reasonably expect a non-trivial cast to happen. What kinds of use cases are motivating this?

I'm not deeply familiar with MC's Asm parsing support, but this looks like a good direction to go.

I've now refreshed the emscripten patches and am hoping they can land soon.

Indeed; after discussing this with a few other folks, I think this is getting close.

My biggest concern here is that this pass shouldn't affect prototype-possessing functions, and that appears to be satisfied :-).

I haven't thought through all the possibilities related to !FD->doesThisDeclarationHaveABody(), but overall this looks good.

In D46805#1115681, @rsmith wrote:

In D46805#1113358, @aaron.ballman wrote:

@rsmith -- do the object file formats listed look correct to you?

They look at least plausible. We should be able to test whether LLVM can actually emit aliases on each of these targets easily enough...

However, I get this error for any WAsm compilation I try:

fatal error: error in backend: section size does not fit in a uint32_t

... so I have no idea if aliases are/will be supported there. Perhaps @sunfish can tell us :)

This looks right to me, but just to make sure I understand, has this been broken since r228400?

LGTM.

Looks good to me. Thanks!

This user-defined custom sections patch should be ready to go now.

We want to coordinate landing this with corresponding changes in Emscripten. Since this is an ABI change, Emscripten needs to figure out how to manage it. See here for ongoing discussion.

Indeed; I don't anticipate LLVM will be using mem.grow or mem.size itself. But, clang has __builtin_wasm_mem_grow and __builtin_wasm_mem_size, to allow standard libraries to use them. It's desirable that the names of these builtins, and the corresponding LLVM IR intrinsics, match the names in the official WebAssembly documentation.

We should probably also wait for the WebAssembly committee to settle on final instruction names.

I'm not very familiar with the Emscripten parts of this, but some grepping in the emscripten tree found these lines:

src/preamble.js:    env['memory'] = Module['wasmMemory'];
src/preamble.js:    env['memory'] = providedBuffer;
src/preamble.js:    assert(env['memory'] instanceof ArrayBuffer);

In D43212#1005708, @sunfish wrote:

The new tests look good, but it'd be good to keep testing "wasm32-unknown-unknown-wasm" and "wasm64-unknown-unknown-wasm" here too.

Please restore the "-wasm" forms of these tests too.

The new tests look good, but it'd be good to keep testing "wasm32-unknown-unknown-wasm" and "wasm64-unknown-unknown-wasm" here too.

I think it's getting closer. IMO we should at least land https://reviews.llvm.org/D43147 and https://reviews.llvm.org/D40526 first, and address any follow-up issues.

I think it's because writeBytes is defined to be passed data from an MCFragment's getContents(), which is a SmallVectorImpl<char>. That's the case here too, though the code that does the getContents() is a little separated from the writeBytes. Following @ncw's suggestion, I created a struct type, which not only avoids repeating the type name, but also makes the use of it cleaner than std::pair.

Created a struct to replace the noisy std::pair code.

@sbc100 I've updated the patch to leave the "env" namespace in place. Do you think this is ready to land now?

There is also an upside to not supporting unprototyped functions. Not only did people writing C in the distant past before prototypes not know what we know today about what it takes to have reasonably robust C code, but leaving C code unmaintained for decades is the opposite of what it takes to have reasonably robust C code, so such code is in double trouble. Obliging people who have unmaintained C codebases to either maintain them or forego using them on new platforms is a positive outcome. It's within reason to assign a variety of relative weights to that outcome, relative to the other outcomes.

In D43097#1002844, @sbc100 wrote:

Sorry maybe I'm jumping the gun here because haven't assigned a reviewer yet..

Add an MC test.

In rL324305#236001, @dschuff wrote:

@sunfish This is really just a change-detector test for the cond code expansion behavior that changed in https://reviews.llvm.org/D42788. Should we consider loosening it so that it just tests that we used the expansion? OTOH it's a bit concerning that that change didn't affect any other tests (!)

As an example, you can have code like this:

#ifdef __wasm__
  // do stuff with __builtin_wasm_mem_grow and __builtin_wasm_mem_size
#endif

which works for both wasm32 and wasm64.

In my experience it's not uncommon to see a reference to "x86" where it's not clear whether it applies to both 32-bit and 64-bit x86, or really just 32-bit x86. Also, I think many of the old architectures have names that predate the existence of their 64-bit variants. For example MIPS was originally 32-bit only. In contrast, RISC-V is an example of a new architecture with a 64-bit variant present from the start, and they call their 32-bit variant riscv32. Consequently, I've been trying to only say "wasm" for things that apply to both wasm32 and wasm64.

• Go back to using "env" for now, so that this is independent of the symbol-table changes and avoids bike-shedding discussions for now.
• Split the clang changes out into a separate patch, which I'll post separately.

I mostly agree. _end/__wasm_end seem reasonable for now. My preference would be to wait on _edata and __bss_start until we know how those might be used.

I'm nervous about adding all these symbols. I like ELF features when they make sense, but for some of these symbols here, it's difficult to think of even hypothetical valid use cases.

Is there a use for _edata? I'm curious how applications would use it differently from _end.

In D37831#871238, @dschuff wrote:

I think the reasoning was really just that code size reduction is even more important on wasm than other platforms, and because it's a new ABI there's no one depending on the default behavior that would break.

Is this fixing a bug? It would help me to see what kind of code triggers this bug.

In D42520#988036, @ncw wrote:

I don't suppose that there's any crossover with C++ modules is there?

In D42520#987422, @ncw wrote:

However, D42495 currently in progress involves changing the way symbols are read from a Wasm object file. There's now going to be an explicit symbol table, so the linker won't resolve all imports, but only imports which correspond to symbols. I guess we could have WasmObjectWriter skip any imports that aren't in the __linker_resolve module, and not create symbols for them; and the linker could merge together imports from the object files that come from other modules...

The LLVM patch, the emscripten-fastcomp-clang patch, and the emscripten patch are now all updated and in sync.

Rebase for upstream changes.

In D42433#985505, @sbc100 wrote:

Maybe once we drop the ELF output comletely we can remove this part?

The codegen tests in LLVM all still use all 4 parts, and I tend to prefer that, because it avoids problems where tests pass on some hosts and fail on others due to LLVM completing the triple by auto-detecting things from the host it's running on. This may not affect wasm today, but it's a habit I'm in from other LLVM work. However, if there are reasons to omit some of the parts in the lld tests, I'm not opposed either.

In rL323220#233942, @sbc100 wrote:

This is a relatively significant change. One that I welcome. But I would have liked to see this go through go review so we could know it was coming and prepare for it. Would you consider lowering your bar a little for the type of changes that got through code review?

To make sure I didn't miss anything, this is just removing the "-wasm" parts now that that's the default, right?

Makes sense. With the direction all the symbol-table things are headed, using the name section as a kind of secondary symbol name is indeed confusing.

Looks good to me. Thanks for cleaning this up!

Ah, I overlooked that the loop doesn't dominate the exit block.

I haven't thought about this in depth, but it seems like SCEV theoretically should be able to cope under such circumstances.

I'm behind on some of the discussions on this topic at the moment, but overall, this looks like it's headed in a good direction, so I'm in favor of this patch.

In D41208#955130, @ncw wrote:

Looks good.

At the back of my mind, I'm just wondering about how Comdat interacts with this. In the .init_array it's fairly simple, since the data section containing the function pointer is handled just like any other data section and is included/excluded as necessary. Is it ever possible for a global ctor to be registered in a COMDAT, maybe for static class members in template classes? In that case we'll need to remember to check that duplicate INIT_FUNCS are discarded (if indeed they can participate in Comdat discarding).

I think the right way to model that would be in the Comdat data. (This is all assuming we do Comdat groups...) Currently Comdat group data is a vector of typed function/data-segment indices. Now that INIT_FUNCS aren't in the .init_array data segment, we'll need to make the Comdat group to be a vector of type function/data-segment/INIT_FUNCS indices.

Either way. I won't be able to get to it until next week, so feel free to land it earlier.

Omitting the start section part for now is ok with me. It should be sufficient to just remove the Priority == UINT16_MAX special cases.

Yes, wasm has its own object format, so this change makes sense.

This updates the patch to make size_t be unsigned long unconditionally, corresponding with the proposed patch to Emscripten here which changes it for asm.js as well.

The issue reported in PR35519 is now fixed, there's a testcase now, and I responded to @sanjoy's comment above.

This update adds @llvm.global_ctors support to the wasm object writer, as layed out here, including init function priorities as sketched here.

For the record, I believe that it would be better to work towards implementing the proposal here:

In D40875#947280, @sbc100 wrote:

Can you update the description.

• Remove the WASM_DEFAULT_LINEAR_MEMORY and WASM_DEFAULT_FUNCTION_TABLE metadata.
• Update test/MC tests.

I'd like to probe the solution of importing the linear memory a little more. There's nothing in wasm that prevents syscalls from working in the wasm start function. The problem seems to just be pre-ES6-module JS. Non-Web, future-ES6-modules-Web, and future programs that are all wasm with no JS won't have this problem.

• Fixes debug info updating.
• Adds a proper testcase for the memset merging caching bug.

This adds a fix for the testcase reported in PR35519; see the change in MemCpyOptimizer.cpp. The code for merging stores into a memset wasn't properly updating memdep's query cache.

Ok, cool. Yeah, I was mainly thinking about --sysroot in clang.

Sysroot is a useful feature on other platforms. What is the reason for removing it, rather than implementing it :-)?