[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.
CHANGES SINCE LAST ACTION
More information about the cfe-commits