Artem-B wrote: > we should probably not represent these as distinct intrinsics in LLVM IR as > it will make adding peephole optimizations for these more difficult
That's a good point, but there are gray areas where compiler convenience should be balanced vs user convenience. In this case, I agree that `sub` variants do not buy us much. > I think there are already many, many cases where LLVM IR is technically valid > but the NVPTX backend cannot lower it due to an unsupported SM or type. I would rather work towards pushing those towards being diagnosed early on, which would give users a chance to recover and properly diagnose the issue within the user app, rather than crashing the compiler, which will be fatal for the application, often with mixed complications on debuggability front. > It would be nice if we could specify a supported set of types for overloaded > intrinsics though, perhaps the intrinsic records could be extended to support > something like this in the future. Agreed. It should be possible to augment verifier so it asks back-end whether particular overload is valid. If we had that in place, then using overloads for sparsely populated parameter space would be a pretty obvious choice. For now, I'm OK with converting to an overloaded intrinsics, despite the current shortcomings. https://github.com/llvm/llvm-project/pull/170079 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
