================
@@ -183,11 +183,12 @@ class LLVM_LIBRARY_VISIBILITY WebAssembly32TargetInfo
const TargetOptions &Opts)
: WebAssemblyTargetInfo(T, Opts) {
if (T.isOSEmscripten())
- resetDataLayout("e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-f128:64-n32:64-"
- "S128-ni:1:10:20");
- else
resetDataLayout(
- "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20");
+ "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-i128:128-f128:64-n32:64-"
+ "S128-ni:1:10:20");
+ else
+ resetDataLayout("e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-i128:128-n32:64-"
+ "S128-ni:1:10:20");
----------------
workingjubilee wrote:
while a preexisting concern and thus not something that should be held against
this PR, it seems slightly unfortunate that so many LLVM targets use
`resetDataLayout`. It's not that I think that overriding the string is a good
idea. Rather, ignoring it makes the ability to set a data-layout string in an
LLVM module merely an attractive nuisance rather than something with actual
utility.
I was going to try to use Compiler Explorer's pass-level diffing view of the
LLVM pipeline to see where the fold that @dschuff noticed was introduced, but
that uses a precompiled LLVM, so it won't have this change. The easiest way to
introduce the modified data-layout to a precompiled LLVM would be a
module-level string, but that seems to do nothing.
I could bother to rebuild LLVM and do things in a much more manual way, of
course, but then what is the ability to pass the string in the module even for?
https://github.com/llvm/llvm-project/pull/119204
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
