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

I thought the target options were older than FMF. I don't think they were
created as a workaround for a shortcoming of FMF. Though that may be what
they've become.

~Craig


On Sat, Oct 30, 2021 at 9:44 AM Wang, Pengfei via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> As far as I understand it, they are two different things.
>
>
>
> Backends used to use target option due to some mechanical problem. But
> backends strictly respect the FMFs in instructions. This is also the reason
> why they use target options that way.
>
> Frontends don’t strictly respect the FMFs in instructions, so if there’s
> no FMFs in instructions, the FMFs are determined by module/function
> attributes.
>
> I think this is the problem Andy wants to solve.
>
> I didn’t learn it much, forgive me if I understand something wrong here :)
>
>
>
> Thanks
>
> Phoebe (Pengfei)
>
>
>
> *From:* Renato Golin <rengolin at gmail.com>
> *Sent:* Sunday, October 31, 2021 12: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>
> 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).
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211030/06734018/attachment-0001.html>

On Sat, 30 Oct 2021 at 17:56, Craig Topper <craig.topper at gmail.com>
wrote:
> I thought the target options were older than FMF. I don't think they
were
> created as a workaround for a shortcoming of FMF. Though that may be what
> they've become.
>
This is what I read from Pengfei's reply. Target options are being used
that way, not created that way.

--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211030/fc614b1b/attachment.html>

I agree that we should remove the target options as an override for FMF.
But we should be aware of a current shortcoming in IR/node-level FMF.
Here's a simple recent example:
https://llvm.org/PR52259

When compiled with -fno-signed-zeros ("nsz"), we want this to be
"llvm.fabs" in IR:

double floatingAbs(double x) {
  if (x < 0) return -x;
  return x;
}

But it doesn't work because the application of FMF is incomplete (or the
FMF design is broken?) - we don't have FMF on function arguments or loaded
FP values.

This patch proposes to solve that example by using function-level
attributes:
https://reviews.llvm.org/D112283

IIUC, removing the target options still allows for the function attribute
override to FMF, so we will still have a potential work-around for the
holes in FMF design/implementation.



On Sat, Oct 30, 2021 at 4:02 PM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Sat, 30 Oct 2021 at 17:56, Craig Topper <craig.topper at
gmail.com> wrote:
>
>> I thought the target options were older than FMF. I don't think
they were
>> created as a workaround for a shortcoming of FMF. Though that may be
what
>> they've become.
>>
>
> This is what I read from Pengfei's reply. Target options are being used
> that way, not created that way.
>
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211101/4150dbba/attachment.html>