cbalint13 wrote: > Put `-mcpu` aside for now, that's nice, but it's only going to be viable in a > world where the backend (tablegen) and frontend (target parsers/ABI info) > agree on what is valid and can also be passed to clang.
> So what your patch produces is kinda like `./bin/clang --target <whatever> > -mllvm -mattr=+unknown_name` and getting `Don't understand unknown_name, you > could have passed . (and we have had customers ask for exactly that sort of > option, but there's a reason some can't be passed to clang) > Unfortunately the information of what is valid to be passed to clang is not > in the same tablegen you're pulling from. It would be nice, and it's not as > far off a goal as it used to be, but we aren't there yet. @DavidSpickett , I see the point with the curated lists vs tablegen backend, thank you much for the explanations. I was only able to check intel's one (w.r.t to -mcpu), without being aware on aarch64 / riscv world's detail. --- My last (potential) idea that might have a purposeful end out of this effort here: 1. For each curated/legit features printed via ```riscvExtensionsHelp()```, ```AArch64::PrintSupportedExtensions()```, ```ARM::PrintSupportedExtensions()``` could be there a lookup within getAllProcessorFeatures() for the human-readable description counterpart ? --- Thanks a lot for your time ! https://github.com/llvm/llvm-project/pull/66586 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
