Oh, you're right, I'm conflating -mexception-handling with -fexceptions. And also -fno-exceptions with noexcept. So... just forget I was here

If this is to be like -fdwarf-exceptions I assume the idea is that eventually it will default on when targeting wasm, and become one of those flags that most users never set. In that case it really just selects the default exception model, and thus it should be compatible with -fno-exceptions just as -fdwarf-exceptions.
Also -fno-exceptions doesn't really mean "no exceptions whatsoever" because if you call something that the compiler isn't sure never throws, it generates an implicit catch-all that calls std::terminate. So how it does that would still be affected by the exception model. (and whatever downstream invoke-removing pass or postprocessing tool might care).

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.

I think the expectation is that if you use an intrinsics header that has an intrinsic for each machine instruction, that each intrinsic call should result in exactly one machine instruction with the same arguments you passed to it. If the vector operation is created some other way (e.g. autovectorization or even __builtin_shufflevector) then I agree that there doesn't necessarily have to be that expectation.

great, LGTM!

Nice.

So it looks like this change is just that we now report an error where it asserted before?

LGTM. Nice that we had a test which tested the wrong thing.

I had a reply that got eaten here, so I'm going to keep trolling you on your CL since we don't have a design doc for this.
The offset field of a data segment initializer can be a global.get on an imported global. (https://webassembly.github.io/spec/core/valid/instructions.html#constant-expressions). Since each thread is separately instantiated with separate JS, we could have a global import like __tls_base which has a different value in each thread. Then we wouldn't need to manually call the init code anywhere. Would there be other advantages or disadvantages for that?

Another high-level question (based just on reading the CL description): The TLS-size intrinsic is per-function, does that mean that the tls-init function is called for every function? are there just multiple TLS sections per object file?

The offset field of a segment can be a constant expression which can be a global.get of an imported global. So we could have an imported global __tls_base which is different for each thread, and have an active segment with that as its segment offset?

Let's work toward getting this landed!
@yurydelendik Your note mentioned that you reverted the breg version based on some kind of incompatibility, can you say more about that?

Oh, btw, any reason these have to be passive segments? Why can't we just make them active segments and let the VM initialize them for us?

If there's any chance this TLS ABI could be useful for WASI (I don't know if there's been any WASI work on threads yet, but it seems like there's no reason it couldn't be), then we should start a doc in tool-conventions for it. If not then we should get it behind the emscripten OS in LLVM. (and document it anyway; either in tool-conventions or somewhere in the emscripten site).

This is fine (assuming getClearCacheBuiltinName is only called when clear_cache is itself called in the source), and an improvement over just asserting. I'm curious to hear what the OP says about their use case, we can always discuss changing this in the future.

LGTM

Another view would be that we accept that this probably doesn't get used in code that would be useful in wasm, but maybe it's in a file that has other useful code, so this would basically be a convenience feature that allows users to have fewer ifdefs in their files (even with the assumption that they aren't going to be calling this code). Someone did, after all, actually run into this problem. Speaking of, maybe we should ask them what their use case is, why they even want to compile this code?

Wow, that was simple.
Is there a "bad" asm parser test we can add now to test this?

LGTM

LGTM in general. Maybe IMPLICITLY_EXPORTED would be an even better name?
Anyway, I'm hoping we can make that export behavior nicer soon; I find the attribute(used) -> export behavior a bit odd too. Once we drop fastcomp it will be easier to redefine EMSCRIPTEN_KEEPALIVE and other things.

LGTM

LGTM modulo the indentation thing.

Yeah I agree with your assessment that this doesn't give us a future-proof ABI; that's why I want to revisit it later. Mostly this is to unblock removing fastcomp.

Given the discussion on the github issues, we have scheduled a discussion at the in-person CG meeting that should resolve the outstanding memory model issues, possibly with a change to the spec.

Otherwise LGTM

This is great! Might it be worth mentioning LLVM_INSTALL_TOOLCHAIN_ONLY somewhere?

LGTM

I assume the linker doesn't need to do anything with this, it can just regenerate it after linking?

I guess the lld code here is an even better answer to my question on the tool-conventions review: the linker behavior is exactly the same.

I think these are leftovers from when we were using ELF.

Reverted in rG039be787914610c28cba45c4557454e0a96939ab. Caused a strange error with the waterfall sysroot's build of libcxx: https://logs.chromium.org/logs/wasm/buildbucket/cr-buildbucket.appspot.com/8917800786005174656/+/steps/libcxx/0/stdout

still LGTM. In a followup CL it should be straightforward to add back fast-isel and you might be able to re-use the same checks in load-store-pic.ll. (but you wouldn't need to add fast-isel+PIC to address-offsets.ll because that's testing an optimization that fast-isel doesn't do.)

otherwise LGTM

to make the change even clearer, you could just say in the commit message that it just adds the missing non-equality opcodes.