llvm dev - Apr 2009 - [LLVMdev] Math Library Intrinsics as native intrinsics

There's at least one other LLVM user which would find these
useful, and probably more, so it may be appropriate to merge
this into the main tree. I'm interested to hear if anyone
else has an opinion here.

An llvm.math namespace seems like a good idea. Instead of
using "fpow" though, I'd prefer to just use names like
"pow". For consistency, the ISD namespace operators could
be renamed to MATH_POW and similar.

The text in LangRef.html that describes the semantics of
llvm.pow needs improvement. Here's an attempt at an
improved description of error handling for LLVM intrinsic
math functions:

The @llvm.math intrinsics use floating-point exceptions
according to IEEE rules for the corresponding math functions.
LLVM IR does not currently define the initial state of the
floating-point status or control flags, or an interface for
querying or setting them. The value of errno after a call to
an @llvm.math intrinsic is undefined.

What do you think?

Dan

On Apr 14, 2009, at 8:39 AM, Villmow, Micah wrote:
> Dan,
> I have a large list of functions(60+) that I want to be legalized. I
> have currently been adding them in the same manner as pow/exp etc...
> These functions come in both scalar and vector versions of up to 16
> elements as the 1.0 spec requires. Is this something that I could
> Merge back into the tree or is another approach required?
> Some of the thoughts we were having as not to clutter the llvm  
> namespace
> was to add a math namespace and the intrinsic would go there instead.
> i.e. llvm.math.fpow, llvm.math.fpowi, llvm.math.fpowr, etc...
>
> Any ideas?
>
> Thanks,
> Micah
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Dan Gohman
> Sent: Monday, April 13, 2009 6:30 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Math Library Intrinsics as native intrinsics
>
>
> On Apr 8, 2009, at 12:43 AM, Duncan Sands wrote:
>
>> Hi Micah,
>>
>>> There seems to be some math library functions that are already
built
>>> into llvm as intrinsic(pow, exp, etc...) but there are lots that
>>> are not
>>> built in yet. Is there currently work going on that is implementing
>>> these? I do not want to duplicate work so I want to see what is out
>>> there.
>>
>> another approach is to get rid of the llvm intrinsics, because they
>> don't buy you anything that you can't get with function
attributes
>> and a list of libcalls.
>
> FWIW, the reason pow, exp, and others were added as intrinsics was to
> allow them to be overloaded with vector types, and to allow them
> to be legalized (split, scalarized, etc.).
>
> Dan
>
> _______________________________________________
> 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

On Apr 14, 2009, at 9:46 AM, Dan Gohman wrote:
> There's at least one other LLVM user which would find these
> useful, and probably more, so it may be appropriate to merge
> this into the main tree. I'm interested to hear if anyone
> else has an opinion here.
I'd rather not see them in the main tree, since there's no real  
explanation of what the benefits would be vs. the current model of  
treating libm calls as actual function calls that pass and return  
arguments of a known type.
> The text in LangRef.html that describes the semantics of
> llvm.pow needs improvement. Here's an attempt at an
> improved description of error handling for LLVM intrinsic
> math functions:
>
> The @llvm.math intrinsics use floating-point exceptions
> according to IEEE rules for the corresponding math functions.
> LLVM IR does not currently define the initial state of the
> floating-point status or control flags, or an interface for
> querying or setting them. The value of errno after a call to
> an @llvm.math intrinsic is undefined.
What is gained by this vs. having a target compile a C libm with LLVM  
using target builtins for the handful of things it actually supports?   
I don't see any explanation of the actual problems people are trying  
to solve here, just "we'd like to make this change".

Nate

Fair enough,
 The current issue that I am having with my backend and the language I
have to support via LLVM is that:
1) I need to support a large number of math functions as language
built-in and not as a separate library. These functions are part of the
core language and thus must be supported on a wide-variety of data types
with very specific rules and definitions for each function, which in
some cases differ to the definition that llvm gives to the same function
name. There are 165 math/integer/relational/geometric specific functions
in section 6.11 of the OpenCL spec, http://www.khronos.org/registry/cl/
when counting for signed/unsigned/floating point variants for some
functions.
2) AMD needs to support these on both GPU and CPU backends so pushing
them to a uniform section is highly desired so we don't have to
duplicate work. Some of these functions are native instructions on the
GPU in either scalar or vector formats but not on the CPU, or vice
versa. 
3) The OpenCL language requires scalar and vector versions up to 16
elements for 8/16/32 bit data types and 8 elements for 64bit data types.
Implementing all of these combinations is an immense amount of work and
this is greatly simplified by utilizing the Legalize/Combine
infrastructure already in place to reduce all the vector types to the
scalar versions.
4) GPU's do not have real support for loading of libraries, so expanding
to a library function approach would not be feasible and this approach
looses the flexibility of the Legalize/Combine infrastructure which as
mentioned earlier is highly desired.
 
Some of the benefits of doing this would be that LLVM would then have
the beginnings of a large built-in reference math library based on, but
not limited to, the OpenCL 1.0 spec. This would allow AMD and possibly
other vendors to utilize this work on various backends without having to
duplicate work. This is work that I am doing internally at AMD anyways,
so for LLVM it will hopefully require minimal work. 

Some of the drawbacks is the large amount of instructions that will be
added might require refactoring parts of the codebase and a large amount
of initial changes to update all the code. Also, there are different
definitions for certain functions compared to the current intrinsic,
where round being one, max/fmax being another, that might cause initial
instruction duplication.

Hope this helps clear up the problem I am approaching. This solution
does not remove the ability of using a math library as the functions can
always be expanded to a function call, but allows usage of LLVM
infrastructure with the math library more easily.

Micah
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Nate Begeman
Sent: Tuesday, April 14, 2009 10:12 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Math Library Intrinsics as native intrinsics


On Apr 14, 2009, at 9:46 AM, Dan Gohman wrote:
> There's at least one other LLVM user which would find these
> useful, and probably more, so it may be appropriate to merge
> this into the main tree. I'm interested to hear if anyone
> else has an opinion here.
I'd rather not see them in the main tree, since there's no real  
explanation of what the benefits would be vs. the current model of  
treating libm calls as actual function calls that pass and return  
arguments of a known type.
> The text in LangRef.html that describes the semantics of
> llvm.pow needs improvement. Here's an attempt at an
> improved description of error handling for LLVM intrinsic
> math functions:
>
> The @llvm.math intrinsics use floating-point exceptions
> according to IEEE rules for the corresponding math functions.
> LLVM IR does not currently define the initial state of the
> floating-point status or control flags, or an interface for
> querying or setting them. The value of errno after a call to
> an @llvm.math intrinsic is undefined.
What is gained by this vs. having a target compile a C libm with LLVM  
using target builtins for the handful of things it actually supports?   
I don't see any explanation of the actual problems people are trying  
to solve here, just "we'd like to make this change".

Nate

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev