-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[WebAssembly] Enable nontrapping-fptoint and bulk-memory by default. #112049
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
c4327c9
8a655be
229888f
d757a4d
6f4d40e
d3e79ec
04b0211
543ee22
a119df5
548564b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
; RUN: llc -filetype=obj %s -o %t.o | ||
; RUN: llc -filetype=obj -mattr=-bulk-memory %s -o %t.o | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we need to disable bulk memory here and in many other files? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In lld/test/wasm/custom-section-name.ll, In lld/test/wasm/data-segments.ll, it's because the test is written to test both bulk-memory and non-bulk-memory, and to keep it doing that, it's now necessary to explicitly disable bulk-memory for the non-bulk-memory case. In lld/test/wasm/lto/stub-library-libcall.s it's because the test is testing the use of a memcpy stub function, and with bulk-memory it gets inlined. llvm/test/MC/WebAssembly/extern-functype-intrinsic.ll is similarly testing memset calls. llvm/test/MC/WebAssembly/libcall.ll is similarly testing memcpy calls. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the explanation! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've now investigated custom-section-name.ll more. With bulk-memory, we get a
Without bulk-memory we get a .bss section:
The test is intended to test the use of the .bss section, and we only get a .bss section in this test if we disable bulk-memory. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, interesting, so we are using passive segments anytime bulk memory is enabled. That makes sense since this was all meant for threads, but is this actually an improvement in the non-threads case? i.e. maybe we don't want the extra explicit initialization code if we can help it? edit: i just checked this out but I'll leave it here FTR: it looks like after linking we actually don't use passive segments unless threads is also enabled. so this seems like not a problem. |
||
; RUN: wasm-ld -no-gc-sections --no-entry -o %t.wasm %t.o | ||
; RUN: obj2yaml %t.wasm | FileCheck %s --check-prefixes=CHECK,NO-BSS | ||
; RUN: wasm-ld -no-gc-sections --no-entry --import-memory -o %t.bss.wasm %t.o | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,8 @@ | ||
target datalayout = "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128" | ||
target triple = "wasm32-unknown-unknown" | ||
|
||
define void @memcpy() { | ||
define void @memcpy() #0 { | ||
ret void | ||
} | ||
|
||
attributes #0 = { "target-features"="-bulk-memory" } |
Uh oh!
There was an error while loading. Please reload this page.