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

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<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/20211030/f9159d32/attachment.html>

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>