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

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.

Thanks
Phoebe (Pengfei)

From: Renato Golin <rengolin at gmail.com>
Sent: Saturday, October 30, 2021 11:41 PM
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 16:01, Wang, Pengfei <pengfei.wang at
intel.com<mailto:pengfei.wang at intel.com>> wrote:
I think the use of target option simply owe to the fact that DAG and other
backend passes always lose the FMFs during transformation in the past.

Ah! That's an interesting piece of information! And exacerbates Eric's
original comment.

At which level is that information lost?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211030/6ee93bbb/attachment.html>

On Sat, 30 Oct 2021 at 17:15, Wang, Pengfei <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/20211030/45ee3835/attachment.html>

> 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>