[llvm] [X86] Adding lowerings for vector ISD::LRINT and ISD::LLRINT (PR #90065)

[Phoebe Wang via llvm-commits]

phoebewang 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.

https://github.com/llvm/llvm-project/pull/90065