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

Thomas Lively via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Feb 8 17:21:18 PST 2019

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.

  rC Clang



More information about the cfe-commits mailing list