================
@@ -1822,6 +1826,29 @@ void X86_64ABIInfo::postMerge(unsigned AggregateSize, 
Class &Lo,
     Hi = SSE;
 }
 
+static X86AVXABILevel getEffectiveX86AVXABILevel(CodeGenTypes &CGT,
+                                                 X86AVXABILevel GlobalAVXLevel,
+                                                 const FunctionDecl *FD) {
+  // Always return global AVX level on PlayStation.
+  if (CGT.getTarget().getTriple().isPS() ||
+      CGT.getContext().getLangOpts().getClangABICompat() <=
+          LangOptions::ClangABI::Ver23) {
+    return GlobalAVXLevel;
+  }
+
+  X86AVXABILevel Level = GlobalAVXLevel;
+  if (!FD || !FD->hasAttr<TargetAttr>())
----------------
freaknbigpanda wrote:

So after thinking about this more over the weekend & this morning, I actually 
think it is fine as is. This change implemented the following semantics:

1. Call site ABI is determined based on caller target attributes
2. Callee’s target attributes affects how the callee itself is compiled
3. Do not force callers with a lower target attribute AVX level to change their 
calling convention, but emit warnings

And the current behaviour with Function Multiversioning matches this, GCC also 
doesn't bother making sure this always produces ABI safe code, and instead just 
emits warnings in cases where it is problematic. For example see 
https://godbolt.org/z/9xKnzdYa1, note that the avx clone of f expects x in ymm 
but the caller doesn't put anything in ymm.

> do you need to check for all of those attributes here?

TLDR: Not in this PR, but there should be a follow up to implement this later.

More detail:

Of the other 3 attributes we only care about `FD->getAttr<TargetClonesAttr>()` 
which is created using __attribute__((target_clones(....)) and 
`FD->getAttr<CPUSpecificAttr>()` which is created using 
`__attribute__((cpu_specific(...))`. The remaining one 
`FD->getAttr<TargetVersionAttr>()` is only relevant for AArch64 and RISC-V.

We need to update both `__attribute__((target_clones(....))` and 
`__attribute__((cpu_specific(...))` to also implement the above semantics, but 
this is a pretty big change, so I think this is best done as a follow up to 
this PR. We can't simply update the if statement to make it work, a lot more 
needs to be done.


https://github.com/llvm/llvm-project/pull/210349
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to