Prince781 wrote: Hi @arsenm, sorry for not replying sooner as I was very busy these past few weeks. Let me respond to several points you raised:
> I maintain that there is no reason to have these intrinsics, and having them > is unnecessary complexity. Trying to surface every knob of every PTX > instruction into an intrinsic should not be a goal. This PR is trying to reduce the complexity of supporting these intrinsics by moving the logic to a target-independent layer. I understand your point about not adding them in the first place, but in some sense the cat is already out of the bag, and we now have many users who depend on these intrinsics. > You can express the same semantics with an explicit flush sequence, which you > can select into your instruction modifier. This counter-proposal suffers all of the problems you ascribe to the original proposal and more. These will be "ghost" instructions which will bloat the IR and undermine any cost model, as code size and register pressure will appear much worse than they really are. > If you want this kind of legalization, we really ought to have generic > intrinsics for fixed rounding mode operations. We're strongly in favor of the [latest strictfp / `fpenv` proposal](https://discourse.llvm.org/t/rfc-yet-another-strict-fp/90798), but we also need a solution that's easier for NVVM clients to adjust to. This feature is only meant to be used for the special cases described, and by making it opt-in for targets we are minimizing the impact. > Trying to treat target intrinsics like an abstract operation is backwards PTX instructions themselves are abstract wrt SASS. This further justifies the unique assumptions we're making for this target. > This is the kind of case that definitely shouldn't be legalized. It's adding > complexity and hidden legalization costs (e.g., the cost model assumes all > intrinsics are cheap by default). Why does this not also apply to existing intrinsics like `@llvm.sin()` etc? > Which is fine and normal, the cost of fully supporting an intrinsic across > all optimization is very high. Pattern matching is a backend responsibility > which should be done anyway We already have hooks in ConstantFolding and elsewhere for these intrinsics. I don't see this creating any new optimization challenges. https://github.com/llvm/llvm-project/pull/194783 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
