[Openmp-commits] [llvm] [openmp] [OpenMPOpt] Analyse loop-runtime callbacks, bound specialization, ask the runtime for the worker count (PR #219323)

[Robert Imschweiler via Openmp-commits]

================
@@ -5830,6 +5911,20 @@ AAFoldRuntimeCall &AAFoldRuntimeCall::createForPosition(const IRPosition &IRP,
   return *AA;
 }
 
+/// Bound the if-cascade AAIndirectCallInfo builds for an indirect call. Device
+/// code routes many parallel regions through a single runtime dispatcher, so a
+/// call site there can see every outlined region in the module; specializing
+/// all of them costs more in code size and compile time than the direct calls
+/// are worth.
+static constexpr unsigned MaxIndirectCallSpecializations = 3;
+
+static bool shouldSpecializeIndirectCallee(Attributor &,
+                                           const AbstractAttribute &,
+                                           CallBase &, Function &,
+                                           unsigned NumAssumedCallees) {
+  return NumAssumedCallees <= MaxIndirectCallSpecializations;
----------------
ro-i wrote:

I think this is an issue, at least if combined with the call site's behavior

https://github.com/llvm/llvm-project/blob/229aa7df428338dcbbae03514aaae74c916f485f/llvm/lib/Transforms/IPO/AttributorAttributes.cpp#L12559-L12561

Since the function is always called with the same number of assumed callees, there is no bound, but just an on/off switch after the threshold. So, with MaxIndirectCallSpecializations = 3 and NumAssumedCallees > 3, we don't get 3 specialized. (I stumbled over this issue downstream where we already have that situation.)

Also, I think the issue is that if there is *no* specialization, we get the callee inlined *twice* into the kernel - once for SPMD, once for non-SPMD. I'm not yet 100% sure of the mechanism, but I think this is worth investigating, otherwise, we might make things worse?

https://github.com/llvm/llvm-project/pull/219323