[PATCH] D57874: [WebAssembly] Make thread-related options consistent

[Thomas Lively via Phabricator via cfe-commits]

tlively added a comment.

In D57874#1391384 <https://reviews.llvm.org/D57874#1391384>, @aheejin wrote:

> In D57874#1391133 <https://reviews.llvm.org/D57874#1391133>, @tlively wrote:
>
> > In D57874#1389953 <https://reviews.llvm.org/D57874#1389953>, @aheejin wrote:
> >
> > > Anyway, moved all logic to the driver layer and did this:
> > >
> > > - `-matomics` means `-mthread-model posix`
> > > - `-mthread-model posix` means `-matomics`
> > > - `-pthread` means both `-matomics` and `-mthread-model posix`
> >
> >
> > If you replace "-matomics" with "-mbulk-memory," I plan to duplicate the logic for items 2 and 3 above, but not 1. For bulk memory even more than atomics, there is a legitimate usecase for enabling it even in single threaded contexts (namely getting to use memory.copy and memory.fill). I wonder if consistency with how bulk memory works is a strong enough argument for dropping item 1 for atomics as well.
>
>
> Then now `-mthread-model posix` means both `-matomics` and `-mbulk-memory`, `-matomics` means `-mthread-model posix`, `-mbulk-memory` means `-mthread-model posix` but NOT `-matomics` means `mbulk-memory` and vice versa, right? Oh god it's complicated.... BTW if you are planning to use `-mthread-model` for turning on and off bulk memory too, why not 1?


We talked about this offline, but recapping here. We can't have `-mbulk-memory` imply `-thread-model posix` because a user might want bulk memory for access to instructions like memory.copy and memory.set (which are just more efficient primitives for memcpy and memset), but NOT want multithreading.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57874