@@ -1200,6 +1225,36 @@ void Writer::createSyntheticInitFunctions() {
}
}
+void Writer::createMemoryGrowFunction() {
+ LLVM_DEBUG(dbgs() << "createMemoryGrowFunction\n");
+ assert(ctx.sym.memoryGrow);
+ std::string bodyContent;
+ {
+raw_string_ostream os(bodyContent);
@@ -249,6 +249,9 @@ aliasname:
\
#define WEAK_ALIAS(name, aliasname)
#define NO_EXEC_STACK_DIRECTIVE
+#elif defined(__wasm__)
+#define NO_EXEC_STACK_DIRECTIVE
sbc100 wrote:
This file looks l
@@ -249,6 +249,9 @@ aliasname:
\
#define WEAK_ALIAS(name, aliasname)
#define NO_EXEC_STACK_DIRECTIVE
+#elif defined(__wasm__)
+#define NO_EXEC_STACK_DIRECTIVE
+
// clang-format on
sbc100 wro
sbc100 wrote:
If this is related specifically to JSPI, perhaps the PR title/description
should include that?
https://github.com/llvm/llvm-project/pull/153767
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
sbc100 wrote:
Looks like perhaps there is a fix in flight:
https://github.com/llvm/llvm-project/pull/151259 ?
https://github.com/llvm/llvm-project/pull/150430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
sbc100 wrote:
This new test as been failing on the emscripten-releases waterfall since it
landed. I'm not sure how or why. See
https://ci.chromium.org/ui/p/emscripten-releases/builders/ci/linux-test-suites/b8707729317947832529/overview
```
@@@BUILD_STEP LLVM regression tests@@@
subprocess.ch
sbc100 wrote:
> clang/test/Preprocessor/wasm-target-features.c looks like its includes
> references to bleeding edge.. not sure why it doesn't require an update.
I guess the test doesn't break when new features are added.. only if they are
removed. Still, it should probably be updated.
https
@@ -197,6 +197,7 @@ bool WebAssemblyTargetInfo::initFeatureMap(
Features["multimemory"] = true;
Features["tail-call"] = true;
Features["wide-arithmetic"] = true;
+Features["gc"] = true;
sbc100 wrote:
If thats really the case we should remove th
sbc100 wrote:
clang/test/Preprocessor/wasm-target-features.c looks like its includes
references to bleeding edge.. not sure why it doesn't require an update.
https://github.com/llvm/llvm-project/pull/151107
___
cfe-commits mailing list
cfe-commits@l
@@ -197,6 +197,7 @@ bool WebAssemblyTargetInfo::initFeatureMap(
Features["multimemory"] = true;
Features["tail-call"] = true;
Features["wide-arithmetic"] = true;
+Features["gc"] = true;
sbc100 wrote:
I would expect to see a corresponding test c
sbc100 wrote:
> My thought is that it returns the return value. If one of the signatures
> matches it sets `*success = 1` otherwise it sets `*success = 0`. It probably
> can be written in terms of `__builtin_wasm_test_function_pointer_signature`
> with C++ templates but lot of projects I contr
sbc100 wrote:
> I'd also like to add `__builtin_wasm_nontrapping_call(&success, func, a, b,
> c)` which tries to call func with 3, 2, 1, and 0 arguments.
Where would the return value go here? Would end up in &success? What happens
if none of the signatures match?
Could you write this in ter
https://github.com/sbc100 commented:
Nice! I think we might be able to use this in a few places in emscripten, to
avoid jumping through JS.
Kind of interesting that this only takes a single argument.. intuitively I
would expect two, but I guess this makes sense.
Would the name `__builtin_wa
https://github.com/sbc100 approved this pull request.
https://github.com/llvm/llvm-project/pull/139580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -52,14 +52,33 @@ static bool CheckWasmBuiltinArgIsInteger(Sema &S, CallExpr
*E,
}
bool SemaWasm::BuiltinWasmRefNullExtern(CallExpr *TheCall) {
- if (TheCall->getNumArgs() != 0)
+ if (TheCall->getNumArgs() != 0) {
sbc100 wrote:
Maybe a comment explaining
@@ -741,6 +741,12 @@ __externref_t externref_null() {
// WEBASSEMBLY-NEXT: ret
}
+int externref_is_null(__externref_t arg) {
+ return __builtin_wasm_ref_is_null_extern(arg);
+ // WEBASSEMBLY: tail call i32 @llvm.wasm.ref.is_null.extern(ptr
addrspace(10) %arg)
sbc100 wrote:
(Nit: We normally spell out `[WebAssembly]` in PR titles)
https://github.com/llvm/llvm-project/pull/139580
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sbc100 closed
https://github.com/llvm/llvm-project/pull/127939
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sbc100 updated
https://github.com/llvm/llvm-project/pull/127939
>From e788e756cac0c7b6f78479adbaea1a86f8005fb6 Mon Sep 17 00:00:00 2001
From: Sam Clegg
Date: Wed, 19 Feb 2025 17:26:41 -0800
Subject: [PATCH] [clang][WebAssembly] Always have `-pthread` imply
`--shared-memory`
https://github.com/sbc100 updated
https://github.com/llvm/llvm-project/pull/127939
>From 19e0415bfefa7724b8149e95a86adf960d786673 Mon Sep 17 00:00:00 2001
From: Sam Clegg
Date: Wed, 19 Feb 2025 17:26:41 -0800
Subject: [PATCH] [clang][WebAssembly] Always have `-pthread` imply
`--shared-memory`
https://github.com/sbc100 created
https://github.com/llvm/llvm-project/pull/127721
None
>From 6d8b255090f08835b8b6b22e7c3d2abfe5ef7531 Mon Sep 17 00:00:00 2001
From: Sam Clegg
Date: Tue, 18 Feb 2025 15:34:13 -0800
Subject: [PATCH] [WebAssembly] Enable extended-const feature by default
---
cl
https://github.com/sbc100 approved this pull request.
https://github.com/llvm/llvm-project/pull/112035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sbc100 updated
https://github.com/llvm/llvm-project/pull/117817
>From 933be68425babeefba6415f5aebc31b0f2d34265 Mon Sep 17 00:00:00 2001
From: Sam Clegg
Date: Tue, 26 Nov 2024 16:38:00 -0800
Subject: [PATCH] [WebAssembly] Implement %llvm.thread.pointer intrinsic. NFC
We can s
sbc100 wrote:
> > Generally LGTM; maybe we also want to add a test for
> > `__builtin_thread_pointer` to clang/test/CodeGen/builtins-wasm.c
>
> I only see that testing in clang/test/CodeGen/builtins-arm64.c, most
> platforms don't seem to test this.
Done!
https://github.com/llvm/llvm-project
https://github.com/sbc100 updated
https://github.com/llvm/llvm-project/pull/117817
>From 9578cf12c95d2511975b9ede6edb3bddc5f5da74 Mon Sep 17 00:00:00 2001
From: Sam Clegg
Date: Tue, 26 Nov 2024 16:38:00 -0800
Subject: [PATCH] [WebAssembly] Implement %llvm.thread.pointer intrinsic. NFC
We can s
sbc100 wrote:
> I guessed that since the "generic" CPU is already out there forcing various
> binary decoders to support this feature, it wouldn't be controversial for
> "lime1" to do it too.
I do think its reasonable for all those decoders to support overlong LEBs.
But I think I don't see
sbc100 wrote:
> The short answer is that's what the [Lime1 CPU calls
> it](https://github.com/WebAssembly/tool-conventions/blob/main/Lime.md#lime1)
> 😄 .
>
> > Can you explain why you want call-indirect-overlong in lime1? Is it because
> > you want to be able to link files compiles with multi
sbc100 wrote:
Can you explain why you want `call-indirect-overlong` in lime1? Is it because
you want to be able to link files compiles with multi-table? i.e. do you
want/expect type relocations at every call_indirect site? If so then perhaps
a better name might be `call-indirect-relocatabl
@@ -854,9 +854,15 @@ and `-mbulk-memory` flags, which correspond to the [Bulk
Memory Operations]
and [Non-trapping float-to-int Conversions] language features, which are
[widely implemented in engines].
+A new Lime1 target CPU is added, -mcpu=lime1. This CPU follows the defin
sbc100 wrote:
I used `wasm-reduce` on the `.ll` file and it looks like you were correct. The
result was:
```
target datalayout =
"e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-f128:64-n32:64-S128-ni:1:10:20"
target triple = "wasm32-unknown-emscripten"
sbc100 wrote:
Perhaps yes. Do you know of any way to reduce the input program into something
we can try to inspect. The preprocessed C++ file is over 100,000 lines :-/
https://github.com/llvm/llvm-project/pull/107257
___
cfe-commits mailing list
cf
sbc100 wrote:
I bisecting this emscripten (wasm32-unknown-emscripten) miscompile to this PR:
https://github.com/emscripten-core/emscripten/issues/22794.
It looks like llvm is generating a load with a negative office (which is not
supported under wasm). There is a reproducer in that but and I
@@ -2,7 +2,7 @@
; RUN: llvm-as -o %t.o %s
; RUN: llvm-as -o %t2.o %S/Inputs/libcall-archive.ll
; RUN: llvm-ar rcs %t.a %t2.o
-; RUN: wasm-ld -o %t %t.o %t.a
+; RUN: wasm-ld -mllvm -mattr=-bulk-memory -o %t %t.o %t.a
sbc100 wrote:
I was thinking that might make
@@ -2,7 +2,7 @@
; RUN: llvm-as -o %t.o %s
; RUN: llvm-as -o %t2.o %S/Inputs/libcall-archive.ll
; RUN: llvm-ar rcs %t.a %t2.o
-; RUN: wasm-ld -o %t %t.o %t.a
+; RUN: wasm-ld -mllvm -mattr=-bulk-memory -o %t %t.o %t.a
sbc100 wrote:
Why is this needed? Should th
https://github.com/sbc100 commented:
lld changes lgtm
https://github.com/llvm/llvm-project/pull/111332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -451,6 +452,18 @@ void SharedFile::parse() {
}
}
+/// Returns the alignment for a custom section. This is used to concatenate
+/// custom sections with the same name into a single custom section.
sbc100 wrote:
We don't use the /// style comment anywhere
https://github.com/sbc100 edited
https://github.com/llvm/llvm-project/pull/111332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sbc100 approved this pull request.
https://github.com/llvm/llvm-project/pull/98373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
sbc100 wrote:
I think the problem with creating a dummy shell script is that it would need to
work on windows too.. I guess it would be better to have test that run on some
platforms that no test at all.
In any case, I'm OK with having this land as-is for now, since this is feature
that is al
https://github.com/sbc100 approved this pull request.
Can we write a test for this?
https://github.com/llvm/llvm-project/pull/98373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
sbc100 wrote:
I think should never not be running wasm-opt when the linker is
wasm-component-ld. Thats not going to work, at least not any time soon.
How to integrate wasm-opt into wasm-component-ld is a good question. I imagine
@alexcrichton has some ideas in that area.
https://github.co
sbc100 wrote:
I wonder if there is some why to avoiding adding this new option globally like
this and instead limit it in scope the wasm target in some way?
https://github.com/llvm/llvm-project/pull/95208
___
cfe-commits mailing list
cfe-commits@li
sbc100 wrote:
> It is hard to fix the clang-format errors because the modified files
> generally don't conform to the clang-format style anyway, so clang-format my
> change currently affects hundreds of unrelated lines.
>
> ```
> aheejin@aheejin:~/llvm-project/libunwind$ git clang-format main
https://github.com/sbc100 approved this pull request.
https://github.com/llvm/llvm-project/pull/92840
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sbc100 approved this pull request.
lgtm.
@dschuff WDYT?
https://github.com/llvm/llvm-project/pull/92604
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1006,6 +1006,8 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
else if (LangOpts.hasDWARFExceptions() &&
(TI.getTriple().isThumb() || TI.getTriple().isARM()))
Builder.defineMacro("__ARM_DWARF_EH__");
+ else if (LangOpts.hasWasmExceptions()
https://github.com/sbc100 edited https://github.com/llvm/llvm-project/pull/92604
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1006,6 +1006,8 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
else if (LangOpts.hasDWARFExceptions() &&
(TI.getTriple().isThumb() || TI.getTriple().isARM()))
Builder.defineMacro("__ARM_DWARF_EH__");
+ else if (LangOpts.hasWasmExceptions()
@@ -1006,6 +1006,8 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
else if (LangOpts.hasDWARFExceptions() &&
(TI.getTriple().isThumb() || TI.getTriple().isARM()))
Builder.defineMacro("__ARM_DWARF_EH__");
+ else if (LangOpts.hasWasmExceptions()
sbc100 wrote:
This change recently rolled into the emscripten SDK and seems to be breaking
the build of regal. I've not invistigated this yet, and its not our code:
```
em++ -c
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/ports/regal/regal-version_7/src/regal/RegalIff.cpp
-o
/usr/lo
https://github.com/sbc100 approved this pull request.
I'm not very familiar with this code, but it looks reasonable on the surface.
https://github.com/llvm/llvm-project/pull/90690
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.ll
sbc100 wrote:
The function being compiled in the crash looks like this one:
https://github.com/emscripten-core/emscripten/blob/56547157a37e25fb31f9193461a2c88bdaa44385/system/lib/embind/bind.cpp#L66-L68
https://github.com/llvm/llvm-project/pull/90310
sbc100 wrote:
This change seems to causing the auto-roller for emscripten to fail due to a
crash in LTO. See
https://ci.chromium.org/ui/p/emscripten-releases/builders/luci.emscripten-releases.ci/linux-test-suites
```
PromoteIntegerOperand Op #3: t22: i32,ch = llvm.coro.subfn.addr t26,
Target
sbc100 wrote:
This change seems to have caused a test in emscripten to starting failing with
`argument unused during compilation: '-O2'`:
https://github.com/emscripten-core/emscripten/pull/21841.
Is that an intended side effect of this change? The fix on our end seems
reasonable but posting
@@ -147,19 +147,25 @@ void
WebAssemblyTargetInfo::setFeatureEnabled(llvm::StringMap &Features,
bool WebAssemblyTargetInfo::initFeatureMap(
llvm::StringMap &Features, DiagnosticsEngine &Diags, StringRef CPU,
const std::vector &FeaturesVec) const {
- if (CPU == "bleedin
sbc100 wrote:
After this lands does that mean that all object files will have `multi-value`
in the features section? Or only object files that actually use `mutli-value`?
https://github.com/llvm/llvm-project/pull/80923
___
cfe-commits mailing li
sbc100 wrote:
Is this good to land now? @yamt do you have commit access or should @aheejin
or myself land this?
https://github.com/llvm/llvm-project/pull/84137
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
https://github.com/sbc100 approved this pull request.
https://github.com/llvm/llvm-project/pull/84569
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -198,9 +198,18 @@
///
/// If there are calls to setjmp()
///
-/// 2) and 3): The same as 2) and 3) in Emscripten SjLj.
-/// (setjmpTable/setjmpTableSize initialization + setjmp callsite
-/// transformation)
+/// 2) In the function entry that calls setjmp, initialize
+///
https://github.com/sbc100 commented:
Let me know if you want some help testing alsongside the emscripten side.
Alternatively myself or @aheejin could perform the emscripten tests.
https://github.com/llvm/llvm-project/pull/84137
___
cfe-commits mailing
https://github.com/sbc100 edited https://github.com/llvm/llvm-project/pull/84137
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -198,9 +198,18 @@
///
/// If there are calls to setjmp()
///
-/// 2) and 3): The same as 2) and 3) in Emscripten SjLj.
-/// (setjmpTable/setjmpTableSize initialization + setjmp callsite
-/// transformation)
+/// 2) In the function entry that calls setjmp, initialize
+///
sbc100 wrote:
> @aheejin @sbc100 let me confirm the plan on this PR. i can remove the option
> `-mllvm -experimental-wasm-enable-alt-sjlj` by making it unconditionally
> true, and update tests, right?
That is my understanding yes.
https://github.com/llvm/llvm-project/pull/84137
__
sbc100 wrote:
> > In terms of getting this landed and tested, I wonder which path we should
> > take:
> >
> > 1. Land this now, without tests, then update emscripten then come back and
> > flip the default, at which point the existing tests will get updated.
> > 2. Duplicate/update the the exi
sbc100 wrote:
> Currently it accepts no extra inputs, but in the future I'd expect that it'll
> grow an option or two of its own
I was more asking about whether the file types is accepts are anything more
than object files and libraries. i.e. can you pass other core modules and have
wasm-com
sbc100 wrote:
I see, so `wasm-ld` builds "core module + metadata" and then
`wasm-component-ld` takes that metadata and uses it to wrap the core module
into a component (with exactly that one core module inside of it).
So the core module + metadata is kind of isomorphic with that
single-core-
sbc100 wrote:
Regarding WebAssembly/wasi-sdk and WebAssembly/wasi-libc, is there any reason
why simple programs wouldn't be core modules? Won't most C/C++ programs still
be build-able as just core modules?
https://github.com/llvm/llvm-project/pull/84569
https://github.com/sbc100 commented:
Does wasm-component-ld accept any other input types other than the ones that
wasm-ld accepts?
Does wasm-component-ld call wasm-ld internally?
Do we expect clang users to be building compound components using a single
clang command? i.e. will they be someh
https://github.com/sbc100 commented:
In terms of getting this landed and tested, I wonder which path we should take:
1. Land this now, without tests, then update emscripten then come back and
flip the default, at which point the existing tests will get updated.
2. Duplicate/update the the exis
@@ -999,25 +1002,42 @@ bool
WebAssemblyLowerEmscriptenEHSjLj::runOnModule(Module &M) {
// Register __wasm_longjmp function, which calls __builtin_wasm_longjmp.
FunctionType *FTy = FunctionType::get(
IRB.getVoidTy(), {Int8PtrTy, IRB.getInt32Ty()}, false);
https://github.com/sbc100 edited https://github.com/llvm/llvm-project/pull/84137
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sbc100 commented:
Thanks for working on this!
I'm excited to see this land and become less emscripten-specific.
I'm hoping that once we get the emscripten side landed we can remove the new
option very soon too.
https://github.com/llvm/llvm-project/pull/84137
_
sbc100 wrote:
> Tried running Emscripten tests, and some of them fail with reference-types or
> bulk-memory. I haven't investigated the causes yet, but it could be better to
> start with the other two (nontrapping-fptoint and multivalue).
No need to block these on emscripten failures.. I'm sur
sbc100 wrote:
@kripken
https://github.com/llvm/llvm-project/pull/80923
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sbc100 approved this pull request.
https://github.com/llvm/llvm-project/pull/79235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -259,10 +259,13 @@ class InputFunction : public InputChunk {
file->codeSection->Content.slice(inputSectionOffset, function->Size);
debugName = function->DebugName;
comdat = function->Comdat;
+assert(s.Kind != WasmSignature::Placeholder);
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
sbc100 wrote:
I think it might be the other way around. It looks like only COFF currently
support
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
sbc100 wrote:
(I'm not sure why `context()` needs to take a template param, and it looks like
its
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
sbc100 wrote:
How about adding a helper like the existing ones `CommonLinkerContext.h`:
```
inline
@@ -40,6 +41,7 @@ using namespace llvm;
namespace lld::wasm {
static std::unique_ptr createLTO() {
lto::Config c;
+ c.EmbedCmdArgs = commonContext().cmdArgs;
sbc100 wrote:
It looks like `commonContext()` is not actually used elsewhere in lld, and this
shou
@@ -259,10 +259,13 @@ class InputFunction : public InputChunk {
file->codeSection->Content.slice(inputSectionOffset, function->Size);
debugName = function->DebugName;
comdat = function->Comdat;
+assert(s.Kind != WasmSignature::Placeholder);
Author: Sam Clegg
Date: 2023-11-02T14:23:45-07:00
New Revision: 89d5635f0a834e53ac5446c6d6ea38d9166b2a55
URL:
https://github.com/llvm/llvm-project/commit/89d5635f0a834e53ac5446c6d6ea38d9166b2a55
DIFF:
https://github.com/llvm/llvm-project/commit/89d5635f0a834e53ac5446c6d6ea38d9166b2a55.diff
LOG
sbc100 wrote:
> But `--no-trap-after-noreturn` didn't exist before, so there was no way to
> specify that from the command line. You _created_ it, originally in this PR,
> and then the split-off PR in #67051. If this is a bugfix, it sounds like you
> are fixing a bug of your own making.
I thi
sbc100 wrote:
> But `--no-trap-after-noreturn` didn't exist before, so there was no way to
> specify that from the command line. You _created_ it, originally in this PR,
> and then the split-off PR in #67051. If this is a bugfix, it sounds like you
> are fixing a bug of your own making.
I thi
sbc100 wrote:
Oh I see I think the issue was Safari: https://webassembly.org/roadmap/. Looks
like this requires Safari 15 :(
https://github.com/llvm/llvm-project/pull/67459
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
https://github.com/sbc100 resolved
https://github.com/llvm/llvm-project/pull/67459
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sbc100 updated
https://github.com/llvm/llvm-project/pull/67459
>From 64d9d8eb1da9f275cde47bd92c39e600e5a2f9b3 Mon Sep 17 00:00:00 2001
From: Sam Clegg
Date: Tue, 26 Sep 2023 09:55:59 -0700
Subject: [PATCH] [WebAssembly] Update generic CPU configuration to include
nontrapping
sbc100 wrote:
@kripken @dschuff @sunfishcode, can you remember why we didn't include this is
part of https://reviews.llvm.org/D125728 and https://reviews.llvm.org/D125729?
Has the landscape changed enough since then that we can/should land this now?
https://github.com/llvm/llvm-project/pull/
https://github.com/sbc100 created
https://github.com/llvm/llvm-project/pull/67459
Enable nontrapping-fptoint in -mcpu=generic. This makes this feature enabled by
default.
This feature is part of [finished proposals], and all major wasm engines
support it.
[finished proposals]:
https://githu
Author: YAMAMOTO Takashi
Date: 2023-08-14T09:36:44-07:00
New Revision: 989ce069a4638fd561bebc95f478ca9e45154fec
URL:
https://github.com/llvm/llvm-project/commit/989ce069a4638fd561bebc95f478ca9e45154fec
DIFF:
https://github.com/llvm/llvm-project/commit/989ce069a4638fd561bebc95f478ca9e45154fec.di
Author: Joel Dice
Date: 2023-06-26T10:31:40-07:00
New Revision: 55e199a2c9f4b218499733d60129deffa0a025fe
URL:
https://github.com/llvm/llvm-project/commit/55e199a2c9f4b218499733d60129deffa0a025fe
DIFF:
https://github.com/llvm/llvm-project/commit/55e199a2c9f4b218499733d60129deffa0a025fe.diff
LOG
Author: Sam Clegg
Date: 2022-09-01T02:56:58-07:00
New Revision: 849df8f6f0a6ded83e36aa52b6daa6b950289804
URL:
https://github.com/llvm/llvm-project/commit/849df8f6f0a6ded83e36aa52b6daa6b950289804
DIFF:
https://github.com/llvm/llvm-project/commit/849df8f6f0a6ded83e36aa52b6daa6b950289804.diff
LOG
Author: Sam Clegg
Date: 2022-06-15T13:56:05-07:00
New Revision: 78747bd39af807eb6b56709b9713c303704c47ad
URL:
https://github.com/llvm/llvm-project/commit/78747bd39af807eb6b56709b9713c303704c47ad
DIFF:
https://github.com/llvm/llvm-project/commit/78747bd39af807eb6b56709b9713c303704c47ad.diff
LOG
Author: Sam Clegg
Date: 2022-06-06T14:04:27-07:00
New Revision: 47039a1a4b299c01dfa0ec531fbc0d24718bb8eb
URL:
https://github.com/llvm/llvm-project/commit/47039a1a4b299c01dfa0ec531fbc0d24718bb8eb
DIFF:
https://github.com/llvm/llvm-project/commit/47039a1a4b299c01dfa0ec531fbc0d24718bb8eb.diff
LOG
Author: Sam Clegg
Date: 2022-03-07T16:45:42-08:00
New Revision: c832edfd3fbccfac6d5212d6495f0dde851dbdde
URL:
https://github.com/llvm/llvm-project/commit/c832edfd3fbccfac6d5212d6495f0dde851dbdde
DIFF:
https://github.com/llvm/llvm-project/commit/c832edfd3fbccfac6d5212d6495f0dde851dbdde.diff
LOG
Author: Sam Clegg
Date: 2022-02-10T16:04:06-08:00
New Revision: ecbcefd693dd62f9242618b3cf838565e829cc7f
URL:
https://github.com/llvm/llvm-project/commit/ecbcefd693dd62f9242618b3cf838565e829cc7f
DIFF:
https://github.com/llvm/llvm-project/commit/ecbcefd693dd62f9242618b3cf838565e829cc7f.diff
LOG
Author: Sam Clegg
Date: 2022-01-31T14:26:09-08:00
New Revision: 45ad3467b708618841869cb529a814001d2295f9
URL:
https://github.com/llvm/llvm-project/commit/45ad3467b708618841869cb529a814001d2295f9
DIFF:
https://github.com/llvm/llvm-project/commit/45ad3467b708618841869cb529a814001d2295f9.diff
LOG
Author: Yuta Saito
Date: 2021-10-19T15:50:08-07:00
New Revision: 1813fde9cc0b56cee42d9b82e6f22fa00a59cdf9
URL:
https://github.com/llvm/llvm-project/commit/1813fde9cc0b56cee42d9b82e6f22fa00a59cdf9
DIFF:
https://github.com/llvm/llvm-project/commit/1813fde9cc0b56cee42d9b82e6f22fa00a59cdf9.diff
LO
Author: Sam Clegg
Date: 2021-08-25T19:24:47-04:00
New Revision: c05d30e444a1208a8a872002d1146b5cf55e370a
URL:
https://github.com/llvm/llvm-project/commit/c05d30e444a1208a8a872002d1146b5cf55e370a
DIFF:
https://github.com/llvm/llvm-project/commit/c05d30e444a1208a8a872002d1146b5cf55e370a.diff
LOG
Author: Sam Clegg
Date: 2021-07-02T11:05:40-07:00
New Revision: d1a96e906cc03a95cfd41a1f22bdda92651250c7
URL:
https://github.com/llvm/llvm-project/commit/d1a96e906cc03a95cfd41a1f22bdda92651250c7
DIFF:
https://github.com/llvm/llvm-project/commit/d1a96e906cc03a95cfd41a1f22bdda92651250c7.diff
LOG
1 - 100 of 136 matches
Mail list logo
