sbc100 added a comment. I don't have documented plan anywhere. I simply observed that we have CPUs called `mvp` and `generic` and it made sense to start including more things in the generic CPU, leaving the `mvp` option open to those who want to be conservative.
I don't think its a huge issue that emscripten should have different default cpu to llvm itself. Emscripten already passes flags to llvm and has different defaults. It even has its own target triple. I confess my main goal here was to be able to encode a configuration which represents the "current spec", but its not "bleeding edge". This also happens to the CPU that the wasi SDK would want to use as I believe almost all the users of wasi-sdk are targeting VMs which include the current spec features. As a less controversial version of this change I could instead create a new CPU called `current` and leave `generic` as is (basically leave it at mvp) until we can agree that a features is widespread enough to warrant being part of generic? Having said that, any*non*-emscripten toolchains that are targeting the web already, like emscripten, have to decide which feature flags to pass by default. Its not something they can avoid. They need to have some opinion. I don't think that llvm and emscripten having different opinions on the default set of features to target is terrible outcome. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77908/new/ https://reviews.llvm.org/D77908 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
