DavidSpickett added a comment. For (1) and (2) is there a need to be able to reset the architecture setting no matter the previous `march` and `<new extension options>` are?
Currently we're talking about *not* wanting having to use `-march=armv8-a+crc` but would you still want a way to reset the architecture no matter what the previous options are? That said, applying the extra extensions to the last `-march` gives you a way to bump the base architecture which could be useful. `-march=armv8-a -add-extension=+crc -march=armv8.4-a` => armv8.4-a+crc. For (3) I agree with your concern. > There are a lot of supported ISA features, so there would be a lot of -m and > -mno- options to document. It would become harder to separate out -m options > related to architecture selection from -m options that do other things. A rough count: $ clang --help | grep " \-m" | wc -l 108 I also wouldn't want to get into a situation where we name an extension such that `-mextension` looks more like it's a general compiler option. E.g. -mnvj Enable generation of new-value jumps "nvj" isn't far off what our extensions end up being called. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113779/new/ https://reviews.llvm.org/D113779 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
