[llvm] [X86] Adding lowerings for vector ISD::LRINT and ISD::LLRINT (PR #90065)
Craig Topper via llvm-commits
llvm-commits at lists.llvm.org
Sat Oct 5 20:51:58 PDT 2024
topperc wrote:
> > > > > Isn't it a poison vaule if the inputs larger than 2^32 according to [LLVM LangRef](https://llvm.org/docs/LangRef.html#trunc-to-instruction)?
> > > >
> > > >
> > > > I think only if the `trunc` would have a `nuw` flag, which isn't present in the reproducer?
> > >
> > >
> > > @fhahn Reviewed the code again, I think it's arguable to consider it's a mis optimization. The reason is not about `trunc` with `nuw` or not, but `llvm.lrint` itself. I think we should consider the difference between `llvm.lrint.i64.f32` and `llvm.llrint.i64.f32`. The front end won't generate `llvm.lrint.i32.f32` for `lrint`, but user might expect `foo` is more optimal than `bar` when they writing
> > > ```
> > > int foo(float x) {
> > > return lrintf(x);
> > > }
> > >
> > > int bar(float x) {
> > > return llrintf(x);
> > > }
> > > ```
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I admit we don't describe `llvm.lrint.i64.f32` in this way, but we can improve it and suggest user to use `llrintf/llvm.llrint.i64.f32` instead when they care about inputs larger than 2^32. WDYT?
> >
> >
> > Doesn't the frontend generate llvm.lrint.i32.f32 on 32-bit targets and on 64-bit Windows? `sizeof(long)` is 4 bytes in those cases.
>
> But they don't have difference on 64-bit Linux, I think it's good to expand its semantic given it's already inconsistent across different target and OS.
Aren't the semantics defined by C not by LLVM IR. How can you change it?
https://github.com/llvm/llvm-project/pull/90065
More information about the llvm-commits
mailing list