[llvm-dev] [RFC] Eliminating non-IR floating-point controls in the selection DAG

[Kaylor, Andrew via llvm-dev]

> Andrew, is that what you're proposing originally? (Sorry if I'm slow to catch, I worried about changing the IR for front-ends but it seems it was misplaced).

If by “that” you mean “relying on the SDNode fast-math flags and not using the target info”, then yes.

I wasn’t aware of the problem that Phoebe brought up with regards to the fast-math flags being dropped. I also haven’t looked to see what is happening in GlobalISel. So, I may be underestimating the amount of work to make this transition. Getting the existing LIT tests to pass doesn’t seem to be a problem. Avoiding all performance regressions in real-world code could be. It may be possible to write a verifier-like utility pass that would try to detect when the flags were lost, but I haven’t thought that through.

As for the transition plan for out-of-tree front ends, I was thinking of something very similar to what Phoebe suggested in her most recent reply on this thread, but I was thinking of having the “fixup” pass run during the codegen prepare phase. The way I envision it would be this:


  1.  Add a field in TargetOptions to disable TargetOption and function attribute control of FP semantics, initially using ‘false’ as the default (keep current behavior)
     *   Front ends that didn’t rely on these options and attributes could change this setting to ‘true’
  2.  Add code to the IR verifier to check for inconsistencies between instruction-level FMF and function attributes (with an option to silence this check)
  3.  Add a pass near CodeGenPrepare that would apply the function attributes and TargetOption FP controls to the IR (inserted FMF where those options allow
     *   Front ends that didn’t rely on these options could omit this pass
  4.  Announce that the FP-related TargetOption and FMF-redundant function attributes were deprecated
  5.  Later, the transition aids above could be removed

-Andy

From: Renato Golin <rengolin at gmail.com>
Sent: Saturday, October 30, 2021 9:28 AM
To: Wang, Pengfei <pengfei.wang at intel.com>
Cc: Kaylor, Andrew <andrew.kaylor at intel.com>; Yaxun Liu <yaxun.liu at amd.com>; Sebastian Pop <sebpop at gmail.com>; Ammarguellat, Zahira <zahira.ammarguellat at intel.com>; Ulrich Weigand <Ulrich.Weigand at de.ibm.com>; Ballman, Aaron <aaron.ballman at intel.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Eliminating non-IR floating-point controls in the selection DAG

On Sat, 30 Oct 2021 at 17:15, Wang, Pengfei <pengfei.wang at intel.com<mailto:pengfei.wang at intel.com>> wrote:
SelectionDAG has many overloaded methods of “getNode”, some of which don’t need to specify the Flags argument. This is reasonable because only FP nodes need that. But it also easily results in losing the Flags in the FP nodes too.
Here’s an example https://reviews.llvm.org/D84518
This problem has been greatly improved since https://reviews.llvm.org/D87361
I think we have the similar problem in MIR based optimizations, but I didn’t dig into it.

This sounds like a somewhat large, but mostly mechanical problem to solve, correct?

Once we have a way to propagate the flags down to instruction selection, then we don't need the target info overriding IR semantics.

Andrew, is that what you're proposing originally? (Sorry if I'm slow to catch, I worried about changing the IR for front-ends but it seems it was misplaced).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211102/52e608d2/attachment.html>