Matt Arsenault via llvm-dev
2016-Jan-28 01:53 UTC
[llvm-dev] [RFC] Canonicalize libcalls to intrinsics
Hi, I would like to propose that when available, if a C builtin function has an equivalent llvm intrinsic, that the intrinsic be the preferred form. The equivalent clang __builtin should emit the intrinsic, and SimplifyLibCalls should replace calls with the intrinsic. For context, this came up on an old review thread: http://reviews.llvm.org/D5896 There are a few motivations for this: 1. Intrinsics have additional properties that help optimizations. They are more widely considered by optimization passes, such as being vectorizable and speculatively executable. 2. More useful for targets where the concept of libcalls is not useful. On GPU targets where there is no machine level linked library, a correct TargetLibraryInfo would report no supported library functions, disabling optimizations on that function. Ideally we could specify libcalls as another function defined in the IR, but that is a separate problem. 3. Consistency. Some __builtins emit the llvm intrinsics, and others do not. 4. It seems unnatural to me to emit a special DAG node for specific calls, then for most targets to later on expand it again as a call later. 5. Eliminate redundant code. Places like ConstantFolding currently have to handle the intrinsic and the libcall -Matt
Joerg Sonnenberger via llvm-dev
2016-Jan-28 13:57 UTC
[llvm-dev] [RFC] Canonicalize libcalls to intrinsics
On Wed, Jan 27, 2016 at 05:53:33PM -0800, Matt Arsenault via llvm-dev wrote:> I would like to propose that when available, if a C builtin function has an > equivalent llvm intrinsic, that the intrinsic be the preferred form. The > equivalent clang __builtin should emit the intrinsic, and SimplifyLibCalls > should replace calls with the intrinsic.As long as you make sure that it deals properly with renames used on the prototypes... E.g. a call to "double sin(double)" can easily be forced to use "my_better_sin_function" on the C level. One huge problem with the "everything as __builtin mess" GCC introduced was to effectively remove any sane way to model such behavior. Joerg
Sanjay Patel via llvm-dev
2016-Jan-29 22:57 UTC
[llvm-dev] [RFC] Canonicalize libcalls to intrinsics
On Thu, Jan 28, 2016 at 6:57 AM, Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Wed, Jan 27, 2016 at 05:53:33PM -0800, Matt Arsenault via llvm-dev > wrote: > > I would like to propose that when available, if a C builtin function has > an > > equivalent llvm intrinsic, that the intrinsic be the preferred form. The > > equivalent clang __builtin should emit the intrinsic, and > SimplifyLibCalls > > should replace calls with the intrinsic. > > As long as you make sure that it deals properly with renames used on the > prototypes... E.g. a call to "double sin(double)" can easily be forced > to use "my_better_sin_function" on the C level. One huge problem with > the "everything as __builtin mess" GCC introduced was to effectively > remove any sane way to model such behavior. >I'm not familiar with what happened to GCC, but I like this proposal because I know there are optimization holes due to not matching both the intrinsic and the libcall. Double --> float shrinking and fmax/fmin are cases I noticed recently. Pulling the intrinsic optimizations out of SimplifyLibCalls should also make it easier to refactor the library function prototype checking. I made a few changes here after https://llvm.org/bugs/show_bug.cgi?id=26211 , but it's still a mess. cc'ing Davide as he might have some ideas about cleaning up SimplifyLibCalls too. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160129/4f8d9481/attachment.html>
Philip Reames via llvm-dev
2016-Jan-30 00:27 UTC
[llvm-dev] [RFC] Canonicalize libcalls to intrinsics
On 01/27/2016 05:53 PM, Matt Arsenault via llvm-dev wrote:> Hi, > > I would like to propose that when available, if a C builtin function > has an equivalent llvm intrinsic, that the intrinsic be the preferred > form. The equivalent clang __builtin should emit the intrinsic, and > SimplifyLibCalls should replace calls with the intrinsic.+1 I think this is a really good cleanup. In particular, the legality matching for known library calls should be in one place and one place only. It's currently spread out all over the place.> > For context, this came up on an old review thread: > http://reviews.llvm.org/D5896 > > There are a few motivations for this: > > 1. Intrinsics have additional properties that help optimizations. They > are more widely considered by optimization passes, such as being > vectorizable and speculatively executable. > 2. More useful for targets where the concept of libcalls is not > useful. On GPU targets where there is no machine level linked library, > a correct TargetLibraryInfo would report no supported library > functions, disabling optimizations on that function. Ideally we could > specify libcalls as another function defined in the IR, but that is a > separate problem. > 3. Consistency. Some __builtins emit the llvm intrinsics, and others > do not. > 4. It seems unnatural to me to emit a special DAG node for specific > calls, then for most targets to later on expand it again as a call later. > 5. Eliminate redundant code. Places like ConstantFolding currently > have to handle the intrinsic and the libcall > > -Matt > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Davide Italiano via llvm-dev
2016-Jan-30 00:34 UTC
[llvm-dev] [RFC] Canonicalize libcalls to intrinsics
On Fri, Jan 29, 2016 at 4:27 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > > On 01/27/2016 05:53 PM, Matt Arsenault via llvm-dev wrote: >> >> Hi, >> >> I would like to propose that when available, if a C builtin function has >> an equivalent llvm intrinsic, that the intrinsic be the preferred form. The >> equivalent clang __builtin should emit the intrinsic, and SimplifyLibCalls >> should replace calls with the intrinsic. >I strongly support this. I'll be more than happy to review the SimplifyLibCalls bits. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
Possibly Parallel Threads
- [LLVMdev] Implementing platform specific library call simplification
- [LLVMdev] Implementing platform specific library call simplification
- [LLVMdev] Implementing platform specific library call simplification
- [LLVMdev] Proposal to merge SimplifyLibCalls into InstCombiner
- [LLVMdev] FunctionPass question