[PATCH] D18751: [MachineCombiner] Support for floating-point FMA on ARM64
James Molloy via llvm-commits
llvm-commits at lists.llvm.org
Tue Apr 5 00:05:11 PDT 2016
Hi Gerolf,
Thanks for the explanation, it makes sense. However Junmo’s point also rings true with some of our microarchitectures. We’ve seen slowdown from decisions the MachineCombiner has made with integer FMADDs in the past (that I’m hoping to address soon), so to me it doesn’t make sense to run the gauntlet of heuristics if there’s no headroom from this optimisation in the microarchitecture.
I’ll run some tests on this patch today to see if it finds improvements. Do you have any particular tests in the test-suite, SPEC2000 or SPEC2006 (or Geekbench?) that you find it improves code for, so I can focus my investigation?
Cheers,
James
> On 5 Apr 2016, at 07:45, Gerolf Hoflehner <ghoflehner at apple.com> wrote:
>
>
>> On Apr 4, 2016, at 9:01 PM, Junmo Park <junmoz.park at samsung.com> wrote:
>>
>> flyingforyou added a comment.
>>
>>> sure, sorry I missed that. I looked at this too long, I guess :-). It is principally the same ‘better ILP' story as for integers. The prototypical idea is this: imagine two fmul operands feeding the fadd. When the two fmul can execute in parallel it can be faster to issue fmul, fmul, fadd rather than fmul, fmadd.
>>
>>
>> I think this opt's effect is depend on uarchitecture implementation. If some OoO uarchitectures can divide fmadd to small uops like fmul and fadd, this optimization is not worth for that kind of uarchitecture. (It's also not good for code-size. This means there is more overhead with instruction fetch.)
> The optimization does not kick when code size is the objective.
>>
>> How about making flag for controling this optimization which is controled by uarch or core?
> So far I have seen gains on at least 3 uArch. As far as I can tell there is no reason to be concerned about compile-time or performance losses. But we can always add a flag when the need arises.
>>
>>
>> http://reviews.llvm.org/D18751
>>
>>
>>
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
More information about the llvm-commits
mailing list