- User Since
- Nov 12 2013, 11:44 AM (275 w, 3 d)
Thu, Feb 7
- -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.
Tue, Feb 5
Mon, Feb 4
- 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.
Fri, Feb 1
I think WebAssembly is in the same situation as most other architectures, as discussed here:
Mon, Jan 28
- 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.
Thu, Jan 24
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.
May 30 2018
May 18 2018
This looks right to me, but just to make sure I understand, has this been broken since r228400?
Apr 9 2018
Apr 4 2018
Looks good to me. Thanks!
Mar 8 2018
This user-defined custom sections patch should be ready to go now.
Mar 2 2018
We want to coordinate landing this with corresponding changes in Emscripten. Since this is an ABI change, Emscripten needs to figure out how to manage it. See here for ongoing discussion.
Indeed; I don't anticipate LLVM will be using mem.grow or mem.size itself. But, clang has __builtin_wasm_mem_grow and __builtin_wasm_mem_size, to allow standard libraries to use them. It's desirable that the names of these builtins, and the corresponding LLVM IR intrinsics, match the names in the official WebAssembly documentation.
Feb 27 2018
We should probably also wait for the WebAssembly committee to settle on final instruction names.
Feb 23 2018
I'm not very familiar with the Emscripten parts of this, but some grepping in the emscripten tree found these lines:
src/preamble.js: env['memory'] = Module['wasmMemory']; src/preamble.js: env['memory'] = providedBuffer; src/preamble.js: assert(env['memory'] instanceof ArrayBuffer);
Feb 20 2018
Feb 15 2018
Feb 12 2018
Please restore the "-wasm" forms of these tests too.
The new tests look good, but it'd be good to keep testing "wasm32-unknown-unknown-wasm" and "wasm64-unknown-unknown-wasm" here too.
Feb 9 2018
I think it's because writeBytes is defined to be passed data from an MCFragment's getContents(), which is a SmallVectorImpl<char>. That's the case here too, though the code that does the getContents() is a little separated from the writeBytes. Following @ncw's suggestion, I created a struct type, which not only avoids repeating the type name, but also makes the use of it cleaner than std::pair.