A little background: The fmuladd intrinsic was introduced to support the FP_CONTRACT pragma in C. llvm.fmuladd.* is generated by clang when it sees an expression of the form 'a * b + c' within a single source statement. If you want to opportunistically form FMA target instructions my inclination would be to skip llvm.fmuladd.* and just form them from a*b+c expressions at isel time. I don't see any fundamental problem with forming llvm.fmuladd.* to model FMA formation opportunities in an IR pass though. - Lang. On Wed, Dec 12, 2012 at 4:11 PM, Michael Ilseman <milseman at apple.com> wrote:> > On Dec 12, 2012, at 3:40 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > > Hi, Dear All: > > I'm going implement FMA formation. On some architectures, "FMA a, b, c" > is more precise than > "a * b + c". I'm wondering if FMA could be less precise. In the former > case, can we enable FMA > formation despite restrictive FP mode? > > > I believe that a pass to form fmuladd[1] intrinsic calls would be very > useful! The fmuladd intrinsic is defined such that its formation should be > isolated from worries about strictness. It simply means "a * b + c" and > leaves the decision of whether or not to fuse up to the code generator. Of > course, one probably would only run your pass if they wanted the code > generator to fuse it, but the pass itself should be valid. > > Someone please correct me if I misunderstand this intrinsic. > > [1] http://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic > > Thanks > Shuxin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/8857172a/attachment.html>
Hi, Eli, Mike and Lang:
Thank you all for the input. This is one e.g which might be
difficult for isel:
a*b + c*d + e => a*b + (c*d + e).
Thanks
Shuxin
On 12/12/12 4:43 PM, Lang Hames wrote:> A little background:
>
> The fmuladd intrinsic was introduced to support the FP_CONTRACT pragma
> in C. llvm.fmuladd.* is generated by clang when it sees an expression
> of the form 'a * b + c' within a single source statement.
>
> If you want to opportunistically form FMA target instructions my
> inclination would be to skip llvm.fmuladd.* and just form them from
> a*b+c expressions at isel time. I don't see any fundamental problem
> with forming llvm.fmuladd.* to model FMA formation opportunities in an
> IR pass though.
>
> - Lang.
>
>
> On Wed, Dec 12, 2012 at 4:11 PM, Michael Ilseman <milseman at apple.com
> <mailto:milseman at apple.com>> wrote:
>
>
> On Dec 12, 2012, at 3:40 PM, Shuxin Yang <shuxin.llvm at gmail.com
> <mailto:shuxin.llvm at gmail.com>> wrote:
>
>> Hi, Dear All:
>>
>> I'm going implement FMA formation. On some architectures,
"FMA
>> a, b, c" is more precise than
>> "a * b + c". I'm wondering if FMA could be less
precise. In the
>> former case, can we enable FMA
>> formation despite restrictive FP mode?
>>
>
> I believe that a pass to form fmuladd[1] intrinsic calls would be
> very useful! The fmuladd intrinsic is defined such that its
> formation should be isolated from worries about strictness. It
> simply means "a * b + c" and leaves the decision of whether
or not
> to fuse up to the code generator. Of course, one probably would
> only run your pass if they wanted the code generator to fuse it,
> but the pass itself should be valid.
>
> Someone please correct me if I misunderstand this intrinsic.
>
> [1] http://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
>
>> Thanks
>> Shuxin
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
> http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/e3a2d1a6/attachment.html>
On Dec 12, 2012, at 4:43 PM, Lang Hames <lhames at gmail.com> wrote:> A little background: > > The fmuladd intrinsic was introduced to support the FP_CONTRACT pragma in C. llvm.fmuladd.* is generated by clang when it sees an expression of the form 'a * b + c' within a single source statement. > > If you want to opportunistically form FMA target instructions my inclination would be to skip llvm.fmuladd.* and just form them from a*b+c expressions at isel time. I don't see any fundamental problem with forming llvm.fmuladd.* to model FMA formation opportunities in an IR pass though. >I see. Shuxin, do you know if it's pretty simple to match FMA style patterns? Is there any advantage to forming them in the IR, e.g. does it allow you to do a post-pass combining or optimization? One major user of FMA formation at the IR level is fast-isel, which could just match those patterns itself if they're simple enough and there's not much subsequent optimization to be had.> - Lang. > > > On Wed, Dec 12, 2012 at 4:11 PM, Michael Ilseman <milseman at apple.com> wrote: > > On Dec 12, 2012, at 3:40 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> Hi, Dear All: >> >> I'm going implement FMA formation. On some architectures, "FMA a, b, c" is more precise than >> "a * b + c". I'm wondering if FMA could be less precise. In the former case, can we enable FMA >> formation despite restrictive FP mode? >> > > I believe that a pass to form fmuladd[1] intrinsic calls would be very useful! The fmuladd intrinsic is defined such that its formation should be isolated from worries about strictness. It simply means "a * b + c" and leaves the decision of whether or not to fuse up to the code generator. Of course, one probably would only run your pass if they wanted the code generator to fuse it, but the pass itself should be valid. > > Someone please correct me if I misunderstand this intrinsic. > > [1] http://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic > >> Thanks >> Shuxin >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/f93b0b4b/attachment.html>
On Dec 12, 2012, at 4:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:> Hi, Eli, Mike and Lang: > > Thank you all for the input. This is one e.g which might be difficult for isel: > a*b + c*d + e => a*b + (c*d + e). >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?> Thanks > Shuxin > > On 12/12/12 4:43 PM, Lang Hames wrote: >> A little background: >> >> The fmuladd intrinsic was introduced to support the FP_CONTRACT pragma in C. llvm.fmuladd.* is generated by clang when it sees an expression of the form 'a * b + c' within a single source statement. >> >> If you want to opportunistically form FMA target instructions my inclination would be to skip llvm.fmuladd.* and just form them from a*b+c expressions at isel time. I don't see any fundamental problem with forming llvm.fmuladd.* to model FMA formation opportunities in an IR pass though. >> >> - Lang. >> >> >> On Wed, Dec 12, 2012 at 4:11 PM, Michael Ilseman <milseman at apple.com> wrote: >> >> On Dec 12, 2012, at 3:40 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: >> >>> Hi, Dear All: >>> >>> I'm going implement FMA formation. On some architectures, "FMA a, b, c" is more precise than >>> "a * b + c". I'm wondering if FMA could be less precise. In the former case, can we enable FMA >>> formation despite restrictive FP mode? >>> >> >> I believe that a pass to form fmuladd[1] intrinsic calls would be very useful! The fmuladd intrinsic is defined such that its formation should be isolated from worries about strictness. It simply means "a * b + c" and leaves the decision of whether or not to fuse up to the code generator. Of course, one probably would only run your pass if they wanted the code generator to fuse it, but the pass itself should be valid. >> >> Someone please correct me if I misunderstand this intrinsic. >> >> [1] http://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic >> >>> Thanks >>> Shuxin >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121212/f7da6e9d/attachment.html>