llvm dev - Jan 2016 - [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

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

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>

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

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