[llvm-dev] [RFC] Canonicalize libcalls to intrinsics

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 29 16:27:42 PST 2016



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



More information about the llvm-dev mailing list