[llvm-dev] Speculative execution of FP divide Instructions - Call-Graph Simplify
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Mar 16 07:49:15 PDT 2017
On 03/15/2017 04:24 PM, Kaylor, Andrew wrote:
>
> >Can you elaborate on this? What do you mean by figuring out where the
> restrictions are needed?
>
> Sure. I’m just referring to having the front end support the
> FENV_ACCESS pragma (or whatever else) to decide for whatever scope it
> is translating whether or not it needs the constrained intrinsics. I
> found one of the places in the front end where it was emitting an fadd
> instruction, and I wrote some code of the form ‘if (true) emit the
> intrinsic instead’ to test out an end-to-end code path. So what’s
> missing is a replacement of that ‘if (true)’ with something that
> actually checks the compilation context to decide what should happen.
>
> I might have been exaggerating a bit when I described this as ‘much
> harder’ but generating the intrinsic is fairly trivial.
>
I think that you should handle this in the same way that we handle the
FP_CONTRACT pragma. If you grep clang for fp_contract and FPContractable
you should see how this works.
-Hal
> -Andy
>
> *From:*Hal Finkel [mailto:hfinkel at anl.gov]
> *Sent:* Wednesday, March 15, 2017 1:55 PM
> *To:* Kaylor, Andrew <andrew.kaylor at intel.com>; Sanjay Patel
> <spatel at rotateright.com>; Samuel Antão <samuelfantao at gmail.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>; acjacob at us.ibm.com
> *Subject:* Re: [llvm-dev] Speculative execution of FP divide
> Instructions - Call-Graph Simplify
>
> On 03/15/2017 01:35 PM, Kaylor, Andrew via llvm-dev wrote:
>
> It’s true, I am working on this. I have committed the initial
> patch to add constrained intrinsics for the basic FP operations.
> This has the desired effect of preventing optimizations that would
> violate strict FP semantics with regard to rounding mode and
> exception status, but it also prevents many safe optimizations.
> Later this year I’ll be going through the code base and trying to
> teach various optimizations to handle the constrained intrinsics
> safely.
>
> Nothing has been added to clang yet to generate these intrinsics,
> though I have some rough code to do so that’s just waiting for an
> implementation of the much harder task of figuring out when such
> restrictions are needed.
>
>
> Can you elaborate on this? What do you mean by figuring out where the
> restrictions are needed?
>
> -Hal
>
>
> If anyone did have a front end that generated these intrinsics,
> everything is in place to get them through to code generation
> (though they currently become at least theoretically unrestricted
> again after ISel). I have an experimental pass that converts all
> basic FP operations to the constrained versions and I’ve been able
> to successfully compile and run real-world FP-using applications
> with that pass in place.
>
> I’m currently working on a patch to add constrained versions of
> the standard library FP intrinsics (sin, cos, pow, etc.).
>
> If anyone is interested in getting pieces of the work-in-progress
> I’ve mentioned above to test drive, let me know. I’d be happy to
> share.
>
> -Andy
>
> *From:*Sanjay Patel [mailto:spatel at rotateright.com]
> *Sent:* Wednesday, March 15, 2017 8:16 AM
> *To:* Samuel Antão <samuelfantao at gmail.com>
> <mailto:samuelfantao at gmail.com>; Kaylor, Andrew
> <andrew.kaylor at intel.com> <mailto:andrew.kaylor at intel.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> <mailto:llvm-dev at lists.llvm.org>; acjacob at us.ibm.com
> <mailto:acjacob at us.ibm.com>
> *Subject:* Re: [llvm-dev] Speculative execution of FP divide
> Instructions - Call-Graph Simplify
>
> > - is there any target for which fp division does not have side
> effects?
>
>
> Yes - all of them. This goes back to the fact that clang/llvm do
> not support changing the FPENV:
> https://bugs.llvm.org/show_bug.cgi?id=8100
>
> There has been some effort to change that recently, so maybe this
> is (partly) fixed? (cc'ing Andy Kaylor)
>
> These reports may also provide info / answers / work-arounds:
>
> https://bugs.llvm.org/show_bug.cgi?id=6050
> https://bugs.llvm.org/show_bug.cgi?id=24343
>
> https://bugs.llvm.org/show_bug.cgi?id=24818
>
> On Wed, Mar 15, 2017 at 3:41 AM, Samuel Antão via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
> Hi all,
>
> I came across an issue caused by the Call-Graph Simplify Pass.
> Here is a a small repro:
>
> ```
>
> define double @foo(double %a1, double %a2, double %a3) #0 {
>
> entry:
>
> %a_mul = fmul double %a1, %a2
>
> %a_cmp = fcmp ogt double %a3, %a_mul
>
> br i1 %a_cmp, label %a.then, label %a.end
>
> a.then:
>
> %a_div = fdiv double %a_mul, %a3
>
> br label %a.end
>
> a.end:
>
> %a_factor = phi double [ %a_div, %a.then ], [ 1.000000e+00,
> %entry ]
>
> ret double %a_factor
>
> }
>
> ```
>
> Here, the conditional is guarding a possible division by zero.
> However if I run CGSimplify on this I get:
>
> ```
>
> define double @foo(double %a1, double %a2, double %a3)
> local_unnamed_addr #0 {
>
> entry:
>
> %a_mul = fmul double %a1, %a2
>
> %a_cmp = fcmp olt double %a_mul, %a3
>
> %a_div = fdiv double %a_mul, %a3
>
> %a_factor = select i1 %a_cmp, double %a_div, double 1.000000e+00
>
> ret double %a_factor
>
> }
>
> ```
>
> This will cause a FP arithmetic exception, and the application
> will get a SIGFPE signal. The code that drives the change in
> the optimizer relies on
> `llvm::isSafeToSpeculativelyExecute` to decide whether the
> division should be performed speculatively. Right now, this
> function returns true. One could do something similar to
> integer divisions and add a case there (this solved the issue
> for me):
>
> ```
>
> diff --git a/lib/Analysis/ValueTracking.cpp
> b/lib/Analysis/ValueTracking.cpp
>
> index 1761dac..c61fefd 100644
>
> --- a/lib/Analysis/ValueTracking.cpp
>
> +++ b/lib/Analysis/ValueTracking.cpp
>
> @@ -3352,6 +3352,21 @@ bool
> llvm::isSafeToSpeculativelyExecute(const Value *V,
>
> // The numerator *might* be MinSignedValue.
>
> return false;
>
> }
>
> + case Instruction::FDiv:
>
> + case Instruction::FRem:{
>
> + const Value *Denominator = Inst->getOperand(1);
>
> + // x / y is undefined if y == 0
>
> + // The denominator is not a constant, so there is nothing
> we can do to prove
>
> + // it is non-zero.
>
> + if (auto *VV = dyn_cast<ConstantVector>(Denominator))
>
> + Denominator = VV->getSplatValue();
>
> + if (!isa<ConstantFP>(Denominator))
>
> + return false;
>
> + // The denominator is a zero constant - we can't
> speculate here.
>
> + if (m_AnyZero().match(Denominator))
>
> + return false;
>
> + return true;
>
> + }
>
> case Instruction::Load: {
>
> const LoadInst *LI = cast<LoadInst>(Inst);
>
> if (!LI->isUnordered() ||
>
> ```
>
> I did my tests using a powerpc64le target, but I couldn't find
> any target specific login involved in this transform. In any
> case, I wanted to drop the questions:
>
> - is there any target that would benefit from speculative fp
> divisions?
>
> - is there any target for which fp division does not have side
> effects?
>
> If not, I can go ahead and post the patch above for review.
>
> Many thanks!
>
> Sam
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> _______________________________________________
>
> LLVM Developers mailing list
>
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/26b0bc61/attachment.html>
More information about the llvm-dev
mailing list