- User Since
- Jan 7 2013, 9:35 AM (340 w, 6 d)
Thu, Jul 18
Tue, Jul 16
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?
Mon, Jul 15
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?
Fri, Jul 12
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).
Tue, Jul 9
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?
Wed, Jul 3
Mon, Jul 1
Wow, that was simple.
Is there a "bad" asm parser test we can add now to test this?
Fri, Jun 28
Thu, Jun 27
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.)
Mar 19 2019
Mar 18 2019
to make the change even clearer, you could just say in the commit message that it just adds the missing non-equality opcodes.
LGTM; I wonder if it makes sense to have predefined macro for the C++ tag (or perhaps just a regular macro for use in libcxxabi?)
Mar 15 2019
wow that's a very large meme.
Mar 14 2019
LGTM assuming that comment is right. Assuming it's correct, I don't really understand what exactly ExternalSymbol actually means though.
Mar 12 2019
So by "correctly" you mean that the TRY goes before the EH_LABEL rather than between the label and the call, and the CATCH goes after the label rather than at the top of the BB?
Mar 7 2019
Mar 5 2019
LGTM with the comment suggestion.
Feb 26 2019
Feb 25 2019
LGTM, this is a nice improvement.
Feb 22 2019
Makes sense. I think the thing that has changed compared to when we started is that symbol types like function, global, and event are more first-class in the wasm object format. Anyway, this change seems fine. I assume the asm parser already isn't using these annotations and we still round-trip?
Is EHPadUnwindMap analogous to any of the similarly-named data structures for WinEH? If so, that would seem to make it even less likely to accidentally break, since any change that breaks it would also break WinEH.