llvm dev - Aug 2018 - Condition code in DAGCombiner::visitFADDForFMACombine?

> On Aug 21, 2018, at 17:57, Ryan Taylor <ryta1203 at gmail.com> wrote:
> 
> Matt,
> I'm sorry, actually it's fma not fmad.
> 
> In the post-legalizer DAG combine for the given code it's producing fma
not fmad. That doens't seem correct.
> 
The contract is on the fadd. I’m not really sure what the rule is supposed to be
for contract between the nodes. The LangRef doesn’t clarify on this. I would
assume it would need to be present on both?

-Matt

The code issue for me seems to be here:
  // Is the node an FMUL and contractable either due to global flags or
  // SDNodeFlags.
  auto isContractableFMUL = [AllowFusionGlobally](SDValue N) {
    if (N.getOpcode() != ISD::FMUL)
      return false;
    return AllowFusionGlobally || isContractable(N.getNode());
  };

The problem is that I'd like to have fast math set but also no contract
nodes that don't specifically have contract/reassoc.

On Tue, Aug 21, 2018 at 11:04 AM Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
>
> > On Aug 21, 2018, at 17:57, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> >
> > Matt,
> > I'm sorry, actually it's fma not fmad.
> >
> > In the post-legalizer DAG combine for the given code it's
producing fma
> not fmad. That doens't seem correct.
> >
>
> The contract is on the fadd. I’m not really sure what the rule is supposed
> to be for contract between the nodes. The LangRef doesn’t clarify on this.
> I would assume it would need to be present on both?
>
> -Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180821/71310268/attachment.html>

As far as being present on both, I'm not sure why that would be the case.
If one instruction doesn't have contract or reassoc, then it should be
allowed to be contracted or reassociated despite any other instruction
flags.

That's my interpretation of what it should mean, otherwise, you'd have
to
pair each possible combination.



On Tue, Aug 21, 2018 at 11:04 AM Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
>
> > On Aug 21, 2018, at 17:57, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> >
> > Matt,
> > I'm sorry, actually it's fma not fmad.
> >
> > In the post-legalizer DAG combine for the given code it's
producing fma
> not fmad. That doens't seem correct.
> >
>
> The contract is on the fadd. I’m not really sure what the rule is supposed
> to be for contract between the nodes. The LangRef doesn’t clarify on this.
> I would assume it would need to be present on both?
>
> -Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180821/8428a019/attachment.html>

For this code:

  %20 = fmul reassoc nnan arcp contract float %15, %19
  %21 = fadd nnan arcp float %20, -1.000000e+00

This does not result in fused multiply-add.

it seems like the logic to contact the fmul from the fadd is different than
whether to decide to contract the fadd. I would think the logic would be
the same for each instruction in the pair.

On Tue, Aug 21, 2018 at 2:05 PM Ryan Taylor <ryta1203 at gmail.com> wrote:
> As far as being present on both, I'm not sure why that would be the
case.
> If one instruction doesn't have contract or reassoc, then it should be
> allowed to be contracted or reassociated despite any other instruction
> flags.
>
> That's my interpretation of what it should mean, otherwise, you'd
have to
> pair each possible combination.
>
>
>
> On Tue, Aug 21, 2018 at 11:04 AM Matt Arsenault <arsenm2 at
gmail.com> wrote:
>
>>
>>
>> > On Aug 21, 2018, at 17:57, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>> >
>> > Matt,
>> > I'm sorry, actually it's fma not fmad.
>> >
>> > In the post-legalizer DAG combine for the given code it's
producing fma
>> not fmad. That doens't seem correct.
>> >
>>
>> The contract is on the fadd. I’m not really sure what the rule is
>> supposed to be for contract between the nodes. The LangRef doesn’t
clarify
>> on this. I would assume it would need to be present on both?
>>
>> -Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180821/470dba4d/attachment.html>