preames wrote: > Related question. If there is an -mcpu on the command line and target > attribute changes the march, do we keep the original CPU in the -target-cpu > attribute or drop it. The reason for all those negative features from the > driver was to make the backend not infer any features from the CPU that > weren't in the provided march. So I'm wondering if we have that issue with > the target attribute now.
It looks like the original -mcpu from the command line is passed through the to the function attributes unless the *cpu* is overridden via the target attribute. Doing a full replacement of the march does not appear to change or remove the target-cpu attribute on the result. One case I could see being problematic would be a CPU which enabled e.g. V, and a replacement march which didn't. Before this change, we'd end up with with an explicit target-feature for +v (coming from the original list passed into cc1), and that's clearly wrong. After this change, we end up with the explicit features being entirely missing (i.e. no explicit +v). I had to go run a test to see what happened from there. It does look like we re-infer from the cpu definition and proceed to generate vector code. Yeah, that's more than a bit suspect. This does fall into the "extension subtraction" case we'd tried to leave out of the specification. So I can see two fixes here: add back the explicit negative feature, or update the specification text to disallow this. https://github.com/llvm/llvm-project/pull/74889 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
