[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