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

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>

Why is isContractableFMUL different from isContractable?

On Tue, Aug 21, 2018 at 3:16 PM Ryan Taylor <ryta1203 at gmail.com> wrote:
> 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/891a7178/attachment.html>

> On Aug 21, 2018, at 23:06, Ryan Taylor <ryta1203 at gmail.com> wrote:
> 
> Why is isContractableFMUL different from isContractable?
If contractable is only expected on the fmul, then what does it even mean to
have it set on any other kind of instruction?