- User Since
- Jan 7 2013, 9:35 AM (349 w, 6 d)
Tue, Sep 17
Thu, Sep 12
Thu, Sep 5
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).
Fri, Aug 30
Thu, Aug 29
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.
Wed, Aug 28
Tue, Aug 27
Mon, Aug 26
Aug 22 2019
Aug 20 2019
So it looks like this change is just that we now report an error where it asserted before?
Aug 19 2019
Aug 15 2019
Aug 14 2019
Aug 13 2019
LGTM. Nice that we had a test which tested the wrong thing.
Aug 12 2019
Aug 8 2019
Aug 7 2019
Jul 18 2019
Jul 16 2019
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?
Jul 15 2019
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?
Jul 12 2019
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).
Jul 9 2019
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.
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?
Jul 3 2019
Jul 1 2019
Wow, that was simple.
Is there a "bad" asm parser test we can add now to test this?
Jun 28 2019
Jun 27 2019
Jun 20 2019
Jun 18 2019
Jun 11 2019
Jun 6 2019
Jun 4 2019
May 29 2019
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.
May 28 2019
LGTM modulo the indentation thing.
May 24 2019
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.
May 21 2019
May 16 2019
This is great! Might it be worth mentioning LLVM_INSTALL_TOOLCHAIN_ONLY somewhere?
Apr 30 2019
Apr 24 2019
Apr 12 2019
I assume the linker doesn't need to do anything with this, it can just regenerate it after linking?
Apr 11 2019
Apr 4 2019
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.
Apr 2 2019
I think these are leftovers from when we were using ELF.
Mar 29 2019
Mar 28 2019
Mar 27 2019
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
Mar 26 2019
Mar 25 2019
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.)