- User Since
- Sep 16 2016, 10:22 AM (108 w, 4 d)
Fri, Oct 12
Tue, Oct 9
Since no tests needed updating I guess we not testing much about the output of --help? Should we add some tests?
Sorry for not replying earlier. Yes, we should generate and preserve size information for data symbols if possible.
Fri, Oct 5
Thanks for the tip, setting a negative threshold helped, and I was able to reduce the test case too.
- add filecheck and minimize test
Thu, Oct 4
I'm not sure it actually does the vectorization in the end. The bit-code that some out is basically identical.
I kind of prefer the test to be as minimal as possible even if derived from c source, but perhaps thats overly pedantic.
This is the smallest test I could create. I would love it to be smaller but it seems hard to tickle this particular path.
- add test
I can trigger the same issue by using __float128 types and --target=i686-linux (where fp128 is emulated in software).
Would bugpoint help here? Its specifically designed to minimize test case I think although I don't have a lot of experience with it myself.
Wed, Oct 3
Is there any way to we can make this test case more focused?
Tue, Oct 2
Your assessment is about right yes. We assembly supports indirect calls but the function signatures have to match in the webassembly type system. In fact the executable won't even validate (won't load) if it contains such invalid calls. So it sounds like the goals are not the same.
Mon, Oct 1
Fri, Sep 28
Rebase and fix tests
Re-opening since we need these symbols to be available pre-LTO.. i.e. before codegen.
Thu, Sep 27
LGTM with nits
Generally looks good. Yay for unblocking us from leaving experimental
Wed, Sep 26
Looks like I broke the doc builder: http://lab.llvm.org:8011/builders/lld-sphinx-docs/builds/26336
We we revert this or get it fixed? Its currently breaking the wasm waterfall: https://wasm-stat.us/console
Tue, Sep 25
OK to land?
Mon, Sep 24
Fri, Sep 21
Do you have a link the broken builder? I'm happy to take a look at fixing this.
Thu, Sep 20
Woah! This a big step people! Congratulations.
I've been persuaded I think that we should rename this, and let emscripten coerce it as it sees fit. However I think maybe we should have common scheme for all these synthetic/internal exports. How about: __wasm_memory, __wasm_table, __wasm_data_start, etc?
Sep 13 2018
Hmm, I see what you mean. I thing is that --export-default is the default, so we would need to detect weather it was set from the command or not which would complicate the code a little. Also, all is a superset of default I'm not sure its necessary.
Sep 12 2018
I don't know this code myself, but if I'm right in assuming this fixes the current waterfall failures then please commit and we can followup is others have comments.
Sep 5 2018
Aug 31 2018
I'm not sure why the logic of this flag is set to true by default and then we check for "!TemporaryWorkarounds".
Aug 29 2018
Aug 22 2018
Aug 21 2018
This change depends on relocations being alwasy stored in offset order, and I'm not convinced that is always that case. I created this change to ensure that llvm always create reloction sections like this but I'm not under what circumstance is might currently fail to do so: https://reviews.llvm.org/D51065
Aug 20 2018
Aug 17 2018
Aug 16 2018
Aug 15 2018
Please ignore this change, I had thought we wanted size_t to match either int32_t or int64_t, but it turns out that isn't a requirement and that code that expects this to be true needs fixing.
Aug 14 2018
- add check for -r
Perhaps I should make this -z compress although I'm not sure what the policy is in using -z keywords vs regular flags.
- fix type mismatch
- add test
Aug 8 2018
Hmm. I don't know the convention. Not a huge and of "The" prefix. LGTM otherwise.
I think you are right about the optimized builds. One thing I thought we might want to preserve is that data objects from the same section should be grouped together contiguously.. but I think we can probably do that while at the same time putting it all in a single segment.
Should we change int32_t as well? Or does the above code just need fixing? I'm a little concerned because this code is very portable which implies that WebAssembly might be doing something unusual here.
I'm running into an issue with an internal codebase that assumes that size_t is equivalent to either int32_t or int64_t which this change invalidates.
I agree this feels a bit awkward, but I prefer to custom bounds checking I think.