[PATCH] D86078: [AArch64] Improved lowering for saturating float to int.

Bevin Hansson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 14 06:24:38 PDT 2020


ebevhan marked an inline comment as done.
ebevhan added inline comments.


================
Comment at: llvm/test/CodeGen/AArch64/fptosi-sat-vector.ll:175
+; CHECK-NEXT:    fcvtzs v0.2d, v0.2d
+; CHECK-NEXT:    xtn v0.2s, v0.2d
 ; CHECK-NEXT:    ret
----------------
efriedma wrote:
> ebevhan wrote:
> > efriedma wrote:
> > > ebevhan wrote:
> > > > efriedma wrote:
> > > > > This should probably just be "fcvtzs v0.2d, v0.2d; sqxtn v0.2s, v0.2d".
> > > > Is sqxtn ever selected without intrinsics? I would assume that a simple minmax and trunc pattern would catch it, but that doesn't happen.
> > > Not sure off the top of my head, but I wouldn't be surprised if the answer is no.  Nobody has spent much time on saturation patterns.
> > > 
> > > The current patch generates xtn?  That isn't saturating, I think?
> > xtn doesn't saturate, no... It just seems to truncate.
> > 
> > But... Doesn't this actually mean that it's wrong? This is supposed to saturate to i32, but it's actually converting to i64 and then truncating. That can't be right.
> > 
> > You weren't wrong about assumptions on node behavior, lowering this to FP_TO_INT clearly didn't do the right thing. So this means that vector FP_TO_INT only saturates if the scalar types are the same bit width? I wonder if the same applies to f16.
> ISD::FP_TO_SINT always has the same semantics as the IR fptosi, regardless of what the actual underlying instructions do.
Ah, certainly. I really meant FCVTZ, not FP_TO_INT.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86078/new/

https://reviews.llvm.org/D86078



More information about the llvm-commits mailing list