sriramshastry wrote: > > > I think a better solution is to just have a pass that runs per-TU that > > > lowers known unsupported intrinsics back into libcalls. > > > > > > It may work. > > One option would be to let us explicitly ask whether the back-end supports > > the intrinsic we may be trying to generate. By default it will reply "yes" > > for generic intrinsics, but some targets may decide to say "no". > > Somewhere at the end of the IR optimizations, we'd have a pass that would > > convert such standard, but non-lowerable intrinsics back to the libcalls, > > if they are available. The pass may be target-specific, so it would not > > need to impact the targets that have the full set of both libcalls and > > intrinsics. > > We already have a pass doing something similar for vector intrinsics: > > llvm/lib/CodeGen/ReplaceWithVeclib.cpp > > Interesting, the important bit is that this is done before the LTO link so we > know which functions to pull in. Unfortunately I don't think there's a good > location that actually states which math calls are supported, but I could > probably make a script that goes through each one. Unless @arsenm knows some > secret backend location.
Hi @jhuber6 , I tested NVPTX archive linking for `llvm.sin.f64`. Pre-rewriting exposed `sin`, but app-defined symbols and a helper cycle showed risks. The synthetic test rewrites before archiving; where could safe lazy-input lowering run? [NVPTX_sine_discussion.zip](https://github.com/user-attachments/files/34240085/NVPTX_sine_discussion.zip) https://github.com/llvm/llvm-project/pull/98209 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
