[PATCH] D69798: Implement inlining of strictfp functions
Andy Kaylor via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 4 15:12:11 PST 2019
andrew.w.kaylor added inline comments.
================
Comment at: llvm/include/llvm/IR/Instruction.h:50
+ /// Indicates that this instruction depends on floating point environment.
+ DependsOnFPEnvironment = 1 << 14,
/// This is a bit stored in the SubClassData field which indicates whether
----------------
It seems wasteful to take one of these bits for something that can be deduced from other information we already have.
================
Comment at: llvm/lib/Transforms/Utils/CloneFunction.cpp:310
+ Instruction *NewInst;
+ if (HostFuncIsStrictFP && OldInst.dependsOnFPEnvironment()) {
+ // Instead of cloning the instruction, a call to constrained intrinsic
----------------
There is some ongoing discussion about how predicated vector instructions will handle constrained FP mode. I think Simon's intention is to have just a single intrinsic that is used regardless of whether strictfp semantics are needed.
Also, in addition to converting fp intrinsics to strict equivalents, I think we need to add the strictfp attribute to callsites. We're currently preventing libcall simplification for callsites marked strictfp. The plan has been for front ends to mark all calls as strictfp so that they don't need to identify math library calls. I could probably be convinced that this is not necessary. Arguably, simplifyLibCalls could look at the callee's function attributes instead. @kpn has been considering whether this behavior should be relaxed.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69798/new/
https://reviews.llvm.org/D69798
More information about the llvm-commits
mailing list