[PATCH] D68857: [X86] Add strict fp support for operations of X87 instructions

LiuChen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 26 01:02:01 PST 2019


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


================
Comment at: llvm/test/CodeGen/X86/fp-strict-scalar.ll:18
 declare float @llvm.experimental.constrained.fdiv.f32(float, float, metadata, metadata)
 declare double @llvm.experimental.constrained.fpext.f64.f32(float, metadata)
 declare float @llvm.experimental.constrained.fptrunc.f64.f32(double, metadata, metadata)
----------------
craig.topper wrote:
> LiuChen3 wrote:
> > Hi, Craig. Is the sequence of "fpext.**f64.f32**" important? I thought it should be fpext.sourcetype.destinationtype, but fpext.f64.f32 can output right code, too.
> > Did this Intrinsic only use pass value type fpext.f64.f32(**float**, metadata) and return value type **double** to determine the source type and return type?
> Its supposed to be fpext.destinationtype.sourcetype.  The types are determined by the order of the llvm_anyint_ty/llvm_anyfloat_ty listed in the Intrinsics.td file with output types before input types.
> 
> But I think the parser doesn't rely on the types in the name and just use the types mentioned. I bet if you feed the test into 'opt' with no other arguments when it gets printed back out the name will have been fixed.
Yes, you are right.  opt will fix the problems. 
Then llvm.experimental.constrained.fptrunc has wrong sequence. Should I update the testcase in this patch or pre-commit the testcase and rebase this patch?


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

https://reviews.llvm.org/D68857





More information about the llvm-commits mailing list