- User Since
- Nov 12 2013, 11:44 AM (284 w, 1 d)
Mon, Apr 22
The theory here is that br_table represents the performance characteristics of a jump table, while br_if represents the performance characteristics of a branch. In hardware, a small switch with 3 cases is often more efficient with a couple of conditional branches than a jump table.
Tue, Apr 16
Mar 19 2019
Mar 18 2019
Mar 14 2019
In the future, atomics will likely be enabled by default, however it will continue to be desirable to be able to select non-shared memory, since non-shared memory doesn't require a maximum size, and since it can make interoperating with JS and other external code simpler. Is it possible to structure this patch in a way that supports this?
Feb 28 2019
I've now made an updated post on https://github.com/WebAssembly/tool-conventions/issues/59.
Wasm gives users reasons to want -mthread-model single that other architectures don't, even when -matomics is enabled by default.
Feb 27 2019
This is still a little confusing to me. -matomic is supposed to be a subtarget flag, stating that the wasm implementation we will run on supports atomic instructions. -mthread-model posix is about the C++ interpretation -- what style implementation of memory model do we want? In the future, -matomic may become enabled by default, when enough wasm engines generally support it. However, -mthread-model single/posix may still be useful to control independently, because even with wasm engines supporting atomic, there are reasons users might still want to compile their apps single-threaded: access to linear memory with no declared max, lower overall code size, or other things.
Feb 25 2019
Feb 7 2019
- -matomics means -mthread-model posix
That sounds reasonable to me too.
- Add MC/WebAssembly and lld tests
- Set the WASM_SYMBOL_NAME_EXPLICIT flag when a symbols name differs from its import name.
Feb 5 2019
Feb 4 2019
- Rename printf_no_Lf to __small_printf.
- Add more tests.
- Split out enabling the iprintf optimization for WASI, to be submitted in a separate patch later.
- Use a symbol flag to indicate when a custom symbol name is present.
- Revert the version number bump.
- Allow globals and events to have custom symbol names too, for consistency.
Feb 1 2019
I think WebAssembly is in the same situation as most other architectures, as discussed here:
Jan 28 2019
- Remove the target constraint, allowing the main rewrite logic to work on all wasm32 targets.
- Remove the now-unneeded "wasm-temporary-workarounds" flag altogether.
- This uncovered some bugs with wrappers for main when main is only a declaration; fix those as well.
Jan 24 2019
Jan 14 2019
Sorry for the delay here. Yes, let's land this.
Or, here's another idea: What if we *just* add "include/wasm-$OS" and don't add "wasm32-$OS" or "wasm64-$OS"-specific include directories? Most headers for wasm will probably be shared between the two, and for anything that really can't be, we always have the __wasm32__ and __wasm64__ predefined macros.
Per @sbc100's comment, this update switches to full multilib paths.
Jan 13 2019
Jan 10 2019
With https://reviews.llvm.org/D48471 and related work, it's not less urgent to do this. And since there were objections to having target-specific warnings anyway, let's close this.
@aheejin The issue is that the current code doesn't distinguish between reading and writing of the stack pointer. Calls don't effectively modify the stack pointer, but they do read the stack pointer. Instructions which modify the stack pointer shouldn't be reordered past calls.
This patch has a review. Is it ready to land?
As @nw points out, clang's lib/Headers/stdint.h doesn't support this yet. Unless anyone feels strongly, I now propose we close this and just leave int_fast16_t/uint_fast16_t as-is.
From a survey and some testing, Emscripten doesn't appear to rely on these paths, so this just affects things like wasmception and the waterfall, which should be straightforward to update.
Dec 13 2018
Dec 10 2018
Do we know what part of the optimizer or codegen is introducing the irreducible control flow in malloc?
Nov 13 2018
-mnan and --with-nan= are MIPS target options, however I'm asking about targeting WebAssembly with a MIPS host.
If I write C code like this:
Nov 11 2018
Oct 18 2018
Can we remove the optional altogether now, and just always do the fixup?
Oct 3 2018
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.
Sep 27 2018
Sep 24 2018
Sep 21 2018
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.
Sep 20 2018
https://reviews.llvm.org/D50568 is now fixed!
Sep 4 2018
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.
Aug 29 2018
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.
Aug 22 2018
Aug 16 2018
This looks ok to land now.
Aug 8 2018
Is this related to the issue reported in the thread here?
Jul 24 2018
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?
Jul 23 2018
Jul 20 2018
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.
Jul 19 2018
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?
Jul 17 2018
I'm not deeply familiar with MC's Asm parsing support, but this looks like a good direction to go.
Jul 11 2018
Jul 10 2018
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.
Jun 25 2018
My biggest concern here is that this pass shouldn't affect prototype-possessing functions, and that appears to be satisfied :-).
Jun 22 2018
I haven't thought through all the possibilities related to !FD->doesThisDeclarationHaveABody(), but overall this looks good.