[PATCH] D27028: Add intrinsics for constrained floating point operations

[Andy Kaylor via llvm-commits]

andrew.w.kaylor added a comment.

In https://reviews.llvm.org/D27028#604172, @hfinkel wrote:

> Based on our conversation at the dev meeting, here's how I thought this would work:
>
> 1. Introduce target-independent chain-carrying nodes to represent these operations. For argument's sake, STRICT_FADD, etc.
> 2. Since nothing in the SDAG knows about what these nodes do, there's no problem with optimizations doing bad things.
> 3. You'd do something minimal in SelectionDAGISel::DoInstructionSelection() around the call to:
>
>   Select(Node);
>
>   so that it would become:
>
>   bool IsStrictFPOp = isStrictFPOp(Node); if (IsStrictFPOp) mutateStrictFPToFP(Node); // STRICT_FADD -> FADD, etc.
>
>   Select(Node);
>
>   if (IsStrictFPOp && !TLI->addStrictFPRegDeps(Node)) report_fatal_error("Could not add strict FP reg deps");
>
>   and then you'd be done. Obviously this is somewhat hand wavy, but if there are complexities I'm overlooking, I'd like to understand them.


Yes, that's exactly what I wanted to do, but I couldn't figure out how to do it.  This is my first time exploring in ISel and it's been a bit intimidating.  The way you describe it sounds very simple.  I guess I was just reluctant to do that because there are currently no target-independent transformations happening there.  I tried putting something in SelectionDAGISel::SelectCommonCode() but it seemed like that was too late for the kind of double transformation I needed (STRICT_FADD->FADD->target-specific instruction).  I'm always hesitant to believe that my new feature is special and really needs something that has never been needed before.  Usually that's a signal that I'm misunderstanding the design.  So I tried to do something that seemed a more natural fit with the existing code.

I'll go back and see what I can do with it following the model you describe here and see what it looks like.


Repository:
  rL LLVM

https://reviews.llvm.org/D27028