Hi Richard, >>> I share Richard E's concern about the effect of this on people who run >>> ./cc1 directly. (And I'm being selfish here, because I regularly run >>> ./cc1 directly on toolchains configured with --with-arch=armv8.2-a+sve.) >>> So TBH my preference would be to keep the TARGET_CPU_DEFAULT_FLAGS stuff. >> >> And what exactly should it do? It didn't work correctly before, and even now >> it's not >> clear what TARGET_CPU_DEFAULT should be set to for all possible combinations >> of >> --with-cpu=X --with-arch=Y --with-tune=Z. Should it have exactly the same >> behaviour >> with and without the driver? If so, that's difficult to achieve in >> config.gcc, and it would >> require a completely different mechanism to ensure the default ends up the >> same >> without the driver (eg. store the original strings in TARGET_CPU_DEFAULT and >> then >> postprocess in the backend as if they were actual --cpu/--arch/--tune >> commands if >> the command-line didn't already set them, ie. replicating what the driver >> already does). >> And it would need to be done for --with-abi as well. > > The specific case I mentioned works well enough though (given that I also > run ./cc1 without -march, -mcpu or -mtune flags). I agree it might not > work for all combinations of --with-arch, --with-cpu and --with-tune, > but I'm not sure that's a strong reason to remove the cases that do work > (or at least, work well enough). This cc1 behaviour is a feature for > developers rather than users after all.
Well how do you suggest we keep the cases that work but block the cases that don't work, but only in cc1 without knowing when someone uses cc1 without the driver? > Perhaps I've missed the point, but why do you need to remove this code > in order to do what you need to do? Basically it's buggy by design. We have 3 related options which are compressed into a single CPU value plus a set of architecture extension flags. That obviously means we can't describe the --with- flags, let alone any combinations, right? For example the architecture to compile for is taken from that single CPU, so the architecture is often wrong (depending on the order of processing in config.gcc). Try bootstrapping trunk using --with-tune=neoverse-n2 to see what I mean. It doesn't just set the tune, it forces an incorrect architecture! My patch works precisely because I ignore the incorrect TARGET_CPU_DEFAULT and allow the driver to do its job properly in prioritizing the options. Then it's a simple matter of reading out the --cpu/arch/tune flags. Like I said, it may be possible to fix this if we pass the --with strings to the backend and process them there. But that means duplicating functionality of the driver for a few users who use cc1. Is that really worth the effort? >> So is changing your preferred config to --with-cpu=neoverse-v1 really a >> problem? > > I specifically want to test generic SVE rather than SVE tuned for a > specific core, so --with-arch=armv8.2-a+sve is the thing I want to test. > I think the question is instead whether it's really a problem to change > my workflow so that I don't run cc1 directly any more, or that I remember > to respecify the --with-arch value as an -march flag when running cc1. > And yeah, maybe the right answer is that I should learn to do that. > It's just that I don't personally understand why this change is necessary. How about creating a macro that adds the --arch for you? Eg. cc1 <args> becomes ./cc1 -march=armv8.2-a+sve <args> Cheers, Wilco
