Ryan Taylor via llvm-dev
2018-Aug-21 19:16 UTC
[llvm-dev] 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>
Ryan Taylor via llvm-dev
2018-Aug-21 20:06 UTC
[llvm-dev] Condition code in DAGCombiner::visitFADDForFMACombine?
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>
Matt Arsenault via llvm-dev
2018-Aug-21 20:37 UTC
[llvm-dev] Condition code in DAGCombiner::visitFADDForFMACombine?
> 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?