[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 abandoned this revision.
sbc100 added a comment.

Yes, on further investigation is seems that there is precedent for having 
`alignof(max_align_t)` and `__BIGGEST_ALIGNMENT__` be different.  See 
https://github.com/emscripten-core/emscripten/pull/19728


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Derek Schuff via Phabricator via cfe-commits]

dschuff added a comment.

After local discussion, I guess we decided to leave this as-is?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

OK to land this?  (With a provision that I will add something to the emscripten 
changelog?)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Derek Schuff via Phabricator via cfe-commits]

dschuff added a comment.

> Presumably this change of change makes most sense in the emscripten ChangeLog 
> right?   We don't tend to document emscripten-specific changes in the llvm 
> release notes do we?

Yes, I think so. Also I think it's more likely to be seen by users in the 
emscripten changelog


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

In D151820#4415754 , @dschuff wrote:

>> As far as I can tell the only way this change could break XNNpack if 
>> XNN_ALLOCATION_ALIGNMENT = 8 is wrongly set there... as long as that is the 
>> correct value for XNN_ALLOCATION_ALIGNMENT I don't see how this change could 
>> break it.  If XNN_ALLOCATION_ALIGNMENT is set wrongly this change might 
>> expose that bug.. but it seems correct to me.
>
> yeah, that's actually what my concern is. IIUC as written the code is asking 
> for 8, but it's being masked by our value of BIGGEST_ALIGNMENT.
>
> I suppose we should land this since I think we do want to have it match 
> max_align_t. But it does make me wonder (again) whether our choice of ABI is 
> correct here.
> Can you also put something in the emscripten release notes about this?

Presumably this change of change makes most sense in the emscripten ChangeLog 
right?   We don't tend to document emscripten-specific changes in the llvm 
release notes do we?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Derek Schuff via Phabricator via cfe-commits]

dschuff added a comment.

> As far as I can tell the only way this change could break XNNpack if 
> XNN_ALLOCATION_ALIGNMENT = 8 is wrongly set there... as long as that is the 
> correct value for XNN_ALLOCATION_ALIGNMENT I don't see how this change could 
> break it.  If XNN_ALLOCATION_ALIGNMENT is set wrongly this change might 
> expose that bug.. but it seems correct to me.

yeah, that's actually what my concern is. IIUC as written the code is asking 
for 8, but it's being masked by our value of BIGGEST_ALIGNMENT.

I suppose we should land this since I think we do want to have it match 
max_align_t. But it does make me wonder (again) whether our choice of ABI is 
correct here.
Can you also put something in the emscripten release notes about this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

Can we land this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

In D151820#4400795 , @tlively wrote:

> In D151820#4385512 , @dschuff wrote:
>
>> I seem to recall that @tlively and I spent a bunch of time with XNNpack 
>> chasing down some kind of subtle error that I suspect had to do with 
>> alignment, but maybe he remembers that better than I do.
>
> Sorry, I have no recollection of this at all 

As far as I can tell the only way this change could break XNNpack if 
XNN_ALLOCATION_ALIGNMENT = 8 is wrongly set there... as long as that is the 
correct value for XNN_ALLOCATION_ALIGNMENT I don't see how this change could 
break it.  If XNN_ALLOCATION_ALIGNMENT is set wrongly this change might expose 
that bug.. but it seems correct to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Thomas Lively via Phabricator via cfe-commits]

tlively added a comment.

In D151820#4385512 , @dschuff wrote:

> I seem to recall that @tlively and I spent a bunch of time with XNNpack 
> chasing down some kind of subtle error that I suspect had to do with 
> alignment, but maybe he remembers that better than I do.

Sorry, I have no recollection of this at all 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a subscriber: ngzhian.
sbc100 added a comment.

In D151820#4385568 , @sbc100 wrote:

> In D151820#4385536 , @dschuff wrote:
>
>>> I don't think it will since `__BIGGEST_ALIGNMENT__ >= 
>>> XNN_ALLOCATION_ALIGNMENT` will remain true after this change.. so this 
>>> change should have no effect on that code.
>>
>> I meant that when `__BIGGEST_ALIGNMENT__ >= XNN_ALLOCATION_ALIGNMENT` (which 
>> was true before and will remain true), then XNNPack uses 
>> `__builtin_alloca()` as the implementation of `XNN_SIMD_ALLOCA` (which 
>> presumably is for allocating SIMD values). This change will reduce the 
>> alignment used by `__builtin_alloca()` from 16 to 8, such that (I think) it 
>> is no longer suitable for SIMD values.
>>
>> Maybe this is a bug in XNNPack (they should maybe be using 
>> XNN_ALLOCATION_ALIGNMENT with a value suitable for SIMD?) but given that 
>> BIGGEST_ALIGNMENT and alloca seem to be intended for any base type 
>> (including SIMD) it wouldn't be surprising if someone else were depending on 
>> this too.
>
> XNN_ALLOCATION_ALIGNMENT is 8 under webassembly, which apparently the 
> alignment than xnnpack wants for webassemebly.  Using alloca for this is find 
> both before and after this change since both 8 and 18 as fit this requirement.
>
>> which... maybe this is just re-litigating the previous discussion, I don't 
>> know. I wonder at what point our ABI should be treating SIMD values as 
>> "normal" rather than rare.

If xnnpack wanted more than 8 byte alignment it should surely set 
XNN_ALLOCATION_ALIGNMENT to greater than 8?

Adding @tlively and @ngzhian in case that have some more background on this..


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

In D151820#4385536 , @dschuff wrote:

>> I don't think it will since `__BIGGEST_ALIGNMENT__ >= 
>> XNN_ALLOCATION_ALIGNMENT` will remain true after this change.. so this 
>> change should have no effect on that code.
>
> I meant that when `__BIGGEST_ALIGNMENT__ >= XNN_ALLOCATION_ALIGNMENT` (which 
> was true before and will remain true), then XNNPack uses `__builtin_alloca()` 
> as the implementation of `XNN_SIMD_ALLOCA` (which presumably is for 
> allocating SIMD values). This change will reduce the alignment used by 
> `__builtin_alloca()` from 16 to 8, such that (I think) it is no longer 
> suitable for SIMD values.
>
> Maybe this is a bug in XNNPack (they should maybe be using 
> XNN_ALLOCATION_ALIGNMENT with a value suitable for SIMD?) but given that 
> BIGGEST_ALIGNMENT and alloca seem to be intended for any base type (including 
> SIMD) it wouldn't be surprising if someone else were depending on this too.

XNN_ALLOCATION_ALIGNMENT is 8 under webassembly, which apparently the alignment 
than xnnpack wants for webassemebly.  Using alloca for this is find both before 
and after this change since both 8 and 18 as fit this requirement.

> which... maybe this is just re-litigating the previous discussion, I don't 
> know. I wonder at what point our ABI should be treating SIMD values as 
> "normal" rather than rare.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Derek Schuff via Phabricator via cfe-commits]

dschuff added a comment.

> I don't think it will since `__BIGGEST_ALIGNMENT__ >= 
> XNN_ALLOCATION_ALIGNMENT` will remain true after this change.. so this change 
> should have no effect on that code.

I meant that when `__BIGGEST_ALIGNMENT__ >= XNN_ALLOCATION_ALIGNMENT` (which 
was true before and will remain true), then XNNPack uses `__builtin_alloca()` 
as the implementation of `XNN_SIMD_ALLOCA` (which presumably is for allocating 
SIMD values). This change will reduce the alignment used by 
`__builtin_alloca()` from 16 to 8, such that (I think) it is no longer suitable 
for SIMD values.

Maybe this is a bug in XNNPack (they should maybe be using 
XNN_ALLOCATION_ALIGNMENT with a value suitable for SIMD?) but given that 
BIGGEST_ALIGNMENT and alloca seem to be intended for any base type (including 
SIMD) it wouldn't be surprising if someone else were depending on this too.

which... maybe this is just re-litigating the previous discussion, I don't 
know. I wonder at what point our ABI should be treating SIMD values as "normal" 
rather than rare.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

In D151820#4385512 , @dschuff wrote:

>> I don't think it will change anything in that code since 
>> `__BIGGEST_ALIGNMENT__ >= XNN_ALLOCATION_ALIGNMENT` will still hold true 
>> both before and after this change (XNN_ALLOCATION_ALIGNMENT == 4 on wasm)
>
> Right, that check causes XNN_ALLOCATION_ALIGNMENT to be ignored in favor of 
> using clang's `_builtin_alloca()` which will be changed by this CL.

I don't think it will since `__BIGGEST_ALIGNMENT__ >= XNN_ALLOCATION_ALIGNMENT` 
will remain true after this change.. so this change should have no effect on 
that code.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Derek Schuff via Phabricator via cfe-commits]

dschuff added a subscriber: tlively.
dschuff added a comment.

> I don't think it will change anything in that code since 
> `__BIGGEST_ALIGNMENT__ >= XNN_ALLOCATION_ALIGNMENT` will still hold true both 
> before and after this change (XNN_ALLOCATION_ALIGNMENT == 4 on wasm)

Right, that check causes XNN_ALLOCATION_ALIGNMENT to be ignored in favor of 
using clang's `_builtin_alloca()` which will be changed by this CL.
I seem to recall that @tlively and I spent a bunch of time with XNNpack chasing 
down some kind of subtle error that I suspect had to do with alignment, but 
maybe he remembers that better than I do.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

In D151820#4385393 , @dschuff wrote:

> I guess this is basically the C version of max_align_t so it should match.

Yes, it should match.   Having `__BIGGEST_ALIGNMENT__` be 16 for emscripten 
doesn't make any sense right now.

> but... this still has the potential to break things.
> e.g. it will change the allocation in 
> https://github.com/google/XNNPACK/blob/master/src/xnnpack/allocator.h#L66
> ISTR that was one of the projects that had an issue with this the first time 
> around?




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

In D151820#4385393 , @dschuff wrote:

> I guess this is basically the C version of max_align_t so it should match.
> but... this still has the potential to break things.

True, but I think it's not as likely the break things as that change the 
max_align_t.. which is more commonly used.

> e.g. it will change the allocation in 
> https://github.com/google/XNNPACK/blob/master/src/xnnpack/allocator.h#L66

I don't think it will change anything in that code since `__BIGGEST_ALIGNMENT__ 
>= XNN_ALLOCATION_ALIGNMENT` will still hold true both before and after this 
change (XNN_ALLOCATION_ALIGNMENT == 4 on wasm)

> ISTR that was one of the projects that had an issue with this the first time 
> around?




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Derek Schuff via Phabricator via cfe-commits]

dschuff added a comment.

I guess this is basically the C version of max_align_t so it should match.
but... this still has the potential to break things.
e.g. it will change the allocation in 
https://github.com/google/XNNPACK/blob/master/src/xnnpack/allocator.h#L66
ISTR that was one of the projects that had an issue with this the first time 
around?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151820/new/

https://reviews.llvm.org/D151820

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151820: [clang][WebAssembly] Fix __BIGGEST_ALIGNMENT__ under emscripten

[Sam Clegg via Phabricator via cfe-commits]

sbc100 created this revision.
Herald added subscribers: pmatos, wingo, sunfish, jgravelle-google, dschuff.
Herald added a project: All.
sbc100 requested review of this revision.
Herald added subscribers: cfe-commits, aheejin.
Herald added a project: clang.

Follow up to https://reviews.llvm.org/D104808 and
https://reviews.llvm.org/D105749.  The only place that seems to be used
is when defining __BIGGEST_ALIGNMENT__ and when choosing the alignment
for the `alloca` builtin.  It seems that both of these should match the
`alignof(max_align_t)` which, for emscripten, is currently 8 bytes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D151820

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/Preprocessor/init.c


Index: clang/test/Preprocessor/init.c
===
--- clang/test/Preprocessor/init.c
+++ clang/test/Preprocessor/init.c
@@ -1500,10 +1500,10 @@
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-unknown-unknown \
 // RUN:   < /dev/null \
-// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32 %s
+// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,WEBASSEMBLY-DEFAULT %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm64-unknown-unknown \
 // RUN:   < /dev/null \
-// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY64 %s
+// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY64,WEBASSEMBLY-DEFAULT %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-emscripten \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,EMSCRIPTEN %s
@@ -1515,10 +1515,10 @@
 // RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY64,EMSCRIPTEN %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-wasi \
 // RUN:   < /dev/null \
-// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,WEBASSEMBLY-WASI %s
+// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,WEBASSEMBLY-DEFAULT,WEBASSEMBLY-WASI 
%s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm64-wasi \
 // RUN:   < /dev/null \
-// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY64,WEBASSEMBLY-WASI %s
+// RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY64,WEBASSEMBLY-DEFAULT,WEBASSEMBLY-WASI 
%s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-unknown-unknown -x c++ \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY-CXX %s
@@ -1537,7 +1537,8 @@
 // WEBASSEMBLY-NEXT:#define __ATOMIC_RELAXED 0
 // WEBASSEMBLY-NEXT:#define __ATOMIC_RELEASE 3
 // WEBASSEMBLY-NEXT:#define __ATOMIC_SEQ_CST 5
-// WEBASSEMBLY-NEXT:#define __BIGGEST_ALIGNMENT__ 16
+// EMSCRIPTEN-NEXT:#define __BIGGEST_ALIGNMENT__ 8
+// WEBASSEMBLY-DEFAULT-NEXT:#define __BIGGEST_ALIGNMENT__ 16
 // WEBASSEMBLY-NEXT:#define __BITINT_MAXWIDTH__ 128
 // WEBASSEMBLY-NEXT:#define __BOOL_WIDTH__ 8
 // WEBASSEMBLY-NEXT:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -984,6 +984,7 @@
 // Emscripten's ABI is unstable and we may change this back to 128 to match
 // the WebAssembly default in the future.
 this->LongDoubleAlign = 64;
+this->SuitableAlign = 64;
   }
 };
 


Index: clang/test/Preprocessor/init.c
===
--- clang/test/Preprocessor/init.c
+++ clang/test/Preprocessor/init.c
@@ -1500,10 +1500,10 @@
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=wasm32-unknown-unknown \
 // RUN:   < /dev/null \
-// RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY32 %s
+// RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,WEBASSEMBLY-DEFAULT %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=wasm64-unknown-unknown \
 // RUN:   < /dev/null \
-// RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY64 %s
+// RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY64,WEBASSEMBLY-DEFAULT %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=wasm32-emscripten \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,EMSCRIPTEN %s
@@ -1515,10 +1515,10 @@
 // RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY,WEBASSEMBLY64,EMSCRIPTEN %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=wasm32-wasi \
 // RUN:   < /dev/null \
-//