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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
