[llvm-dev] Condition code in DAGCombiner::visitFADDForFMACombine?

Ryan Taylor via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 21 13:06:23 PDT 2018


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>


More information about the llvm-dev mailing list