[llvm] [X86] Combine LRINT/LLRINT and TRUNC when nuw/nsw (PR #126217)
Phoebe Wang via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 7 23:58:06 PST 2025
phoebewang wrote:
> Do you have examples where we are able to infer an nuw/nsw flag for a truncate after lrint?
Not yet. The idea was inspired by the discussions from @andykaylor and @jcranmer-intel in https://github.com/llvm/llvm-project/issues/125324, i.e., we need a flag works for the purpose of `no-overflow`. And the nuw/nsw flags on trunc looks the best solution to me. But I don't think the flags can be infered by compiler, unless e.g., we have a range data bind to the trunc or lrint instruction. The expected scenario is user explicitly set it with some FE help.
For now, I only have some draft ideas like generating nuw/nsw flags when user specify it through Clang option. This may bring unexpected result if we apply it globally, so I also have an idea that user can specify it through builtin like __builtin_assume for only those that they want. But I don't know if it's easy to implement. The last idea is to provide a new builtin, e.g., __builtin_trunc_nuw/nsw for the purpose. It is the easiest way we can implement.
In a word, I don't worry about the user scenario. And it looks to me a reasonable from the backend's perspective.
> I was also wondering if it would be reasonable to apply this transformation in InstCombine -- for instance, convert `llvm.lrint.i64.f64+(nsw/nuw)trunc` to `llvm.rint.i32`? That's assuming we have reason to believe that this is useful.
The concern of putting it in the middle end is we don't know if a target prefers to use small size lrint and to which size it prefers the most. I'm afraid backend may geneate suboptimal code if we arbitrarily combine to `llvm.rint.i16` or `llvm.rint.i8`.
https://github.com/llvm/llvm-project/pull/126217
More information about the llvm-commits
mailing list