[PATCH] D47691: [NVPTX] Ignore target-cpu and -features for inling

[Artem Belevich via Phabricator via llvm-commits]

tra added inline comments.


================
Comment at: lib/Target/NVPTX/NVPTXTargetTransformInfo.h:66
+  // attributes that were added to newer versions of LLVM/Clang: There are
+  // no incompatible functions in PTX, ptxas will throw errors in such cases.
+  bool areInlineCompatible(const Function *Caller,
----------------
Hahnfeld wrote:
> tra wrote:
> > hfinkel wrote:
> > > "We can ignore potential problems in inlining because the assembler will generate errors later if we do the wrong thing" is probably not what we mean. Obviously the point of this function is to avoid inlining when that might cause a problem later (either in tools, such as the assembler, or at runtime). 
> > > 
> > > My understanding, from the ongoing discussions, is that PTX is backward compatible, and ptxas will generate code for the underlying target for all PTX uniformly during any given compilation (and, thus, regardless of what the attributes say, the generated machine code will use features from the most-recent specified target. This might not be completely true (i.e., ptxas might still generate code in light of different legalization decisions), but it might be true enough to be the desired behavior.
> > We're talking about two  issues here:
> > 
> > * what should be done with functions that have target-cpu or target-feature that's not compatible with the current compilation mode?
> > 
> > Right now the assumption is that the IR we're given is valid (as in - compilable) for the given compilation mode. At the very least, I can successfully compile functions with target-cpu=sm_70 with llc -march=aarch64.
> > 
> > If that's not the case, results may vary from success to partial success (suboptimal code due to some instructions being unavailable), to a failure during compilation (unavailable intrinsics) to PTX or, finally, a failure during compilation of PTX->SASS (e.g. invalid instruction in inline assembly)). I'm not aware of a good way to deal with incompatible IR in LLVM and that's not NVPTX-specific.
> > 
> > * What inlining restrictions should we impose on the functions we deemed acceptable for compilation?
> > If the assumption above is true, then we have no reason (in NVPTX)  to prevent linkining based on these attributes, because every one of them is compilable, which in turn means that it's executable on the target GPU.  The goal of preventing inlining here was to avoid executing incompatible code.
> > 
> > Bottom line -- the situation is far from perfect, but IMO the patch does sensible thing if we're compiling IR with mixed target-cpu and target-features attributes using NVPTX.
> (To be honest I don't understand the point of `areInlineCompatible` at all: Either that function can be compiled in which case it doesn't matter if it is called or inlined, or it is invalid which will result in an error...)
My understanding is that it's needed to support function multiversioning in clang which will only work if functions are not inlined:
https://clang.llvm.org/docs/AttributeReference.html#target-gnu-target  https://gcc.gnu.org/wiki/FunctionMultiVersioning



Repository:
  rL LLVM

https://reviews.llvm.org/D47691