llvm dev - Dec 2012 - [LLVMdev] Question about FMA formation

On Dec 12, 2012, at 5:20 PM, Eric Christopher <echristo at gmail.com>
wrote:
> Why not just form them via a fast IR level pass and just have patterns
match in fast isel instead of trying to form code? Or are we saying the same
thing? (Your words of "fast isel spot"ting and "form better
code" caused me to think you mean to do optimizations within the fast isel
pass).
Sorry, we've kind of been jumping around a bit. I'll try to expound on
what's being debated: We have a few options ahead of us as far as
benefitting fast-isel is concerned.

We can write a pass to form fmuladds. The intent being to run this very late,
perhaps before or part of codegen prepare. The downside here is that it somewhat
goes against the point of fast-isel. Fast-isel allows us to skip extra
representations of the program, and replacing IR with intrinsic calls is similar
to having an extra representation, albeit only for part of the program.

However, the basic task of spotting an fadd of an fmul is simple enough that
fast-isel could just emit the FMA equivalent if it likes. This has the benefit
that we avoid the extra representation, but the downside that it makes fast-isel
a little more complicated and it only does simple patterns.

Shuxin was showing some more complicated patterns that required re-association
to match (fast-math flags permitting). For those, we're considering if
having a re-associate-for-FMA functionality in codegen-prepare would solve that
problem. Thus, we can re-associate in codegen-prepare and emit FMA in fast-isel.

> -eric
> 
> On Wed, Dec 12, 2012 at 5:14 PM, Michael Ilseman <milseman at
apple.com> wrote:
>> Right now we're shying towards having a re-association helper in
codegen-prepare that will re-associate expressions (if allowed). This would
allow fast-isel to more easily spot FMA opportunities, and form better code.
>> 
>> On Dec 12, 2012, at 5:11 PM, Eric Christopher <echristo at
gmail.com> wrote:
>> 
>>> 
>>> 
>>> 
>>>> You hit send right when I did!
>>>> For your example, do you mean that it's grouped like:
>>>> (fadd (fadd (fmul a b) (fmul c d)) e)
>>>> 
>>>> How would your pass go about handling these patterns and is
that something that would be too complicated for fast-isel to do on the fly?
>>> 
>>> Depends on how they're grouped, but if the formation happens
prior to codegen then fast-isel will just handle whatever new instruction
you've got. An example of IR would be useful though :)
>>> 
>>> -eric
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/db5d4cb5/attachment.html>

Hi Michael, Shuxin,

> Shuxin was showing some more complicated patterns that required
> re-association to match (fast-math flags permitting). For those, we're
> considering if having a re-associate-for-FMA functionality in
> codegen-prepare would solve that problem. Thus, we can re-associate in
> codegen-prepare and emit FMA in fast-isel.
>
Yep. I misread the association on Shuxin's example, but even ((a*b) +
(c*d)) + e would match to a 3-instructions:
(fadd (fma a b (fmul c d)) e).

If there are hairier examples that really require reassociation my vote
would be for this last scheme: An FMA-friendly reassociation pass run
before isel that exposes simple patterns for isel to match.

- Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/c16ba2a1/attachment.html>

On Wed, Dec 12, 2012 at 8:34 PM, Lang Hames <lhames at gmail.com> wrote:
> Hi Michael, Shuxin,
>
>
>> Shuxin was showing some more complicated patterns that required
>> re-association to match (fast-math flags permitting). For those,
we're
>> considering if having a re-associate-for-FMA functionality in
>> codegen-prepare would solve that problem. Thus, we can re-associate in
>> codegen-prepare and emit FMA in fast-isel.
>>
>
> Yep. I misread the association on Shuxin's example, but even ((a*b) +
> (c*d)) + e would match to a 3-instructions:
> (fadd (fma a b (fmul c d)) e).
>
> If there are hairier examples that really require reassociation my vote
> would be for this last scheme: An FMA-friendly reassociation pass run
> before isel that exposes simple patterns for isel to match.
>
>
Agreed. I don't think fast isel should be attempting to form any new
patterns.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/ee3b487f/attachment.html>