| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Use separate implementations instead of a macro
to ensure the constant multiplied with is of
higher precision.
v2: Use the correct formula, spotted by Dan Liew <daniel.liew@imperial.ac.uk>
Reviewed-by: Aaron Warty <awatry@gmail.com>
Reviewed-by: Tom Stellard <tom@stellard.net>
llvm-svn: 210891
|
|
|
|
| |
llvm-svn: 209850
|
|
|
|
|
|
|
|
|
| |
The 'f' was missing and, hence, the values were
considered to be doubles instead of floats.
Reviewed by: Tom Stellard
llvm-svn: 209849
|
|
|
|
|
|
| |
Reviewed by: Tom Stellard
llvm-svn: 209848
|
|
|
|
|
|
|
|
|
| |
This file duplicates clc/math/gentype.inc and is not
actually being used.
Patch by: Jeroen Ketema
llvm-svn: 207684
|
|
|
|
|
|
| |
Patch by: Jeroen Ketema
llvm-svn: 205055
|
|
|
|
|
|
| |
Patch by: Jeroen Ketema
llvm-svn: 205054
|
|
|
|
|
|
|
|
|
|
| |
v2:
- Use a hexadecimal constant.
v3:
- Use a hexadecimal constant in floating-point notation.
llvm-svn: 204666
|
|
|
|
|
|
|
| |
Patch by: Jeroen Ketema
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 204478
|
|
|
|
|
|
|
| |
Patch by: Jeroen Ketema
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 204477
|
|
|
|
|
|
|
|
| |
v2:
- Fix typo.
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 197784
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenCL C lang says that trunc rounds towards zero.
llvm.trunc.* intrinsic rounds to integer not larger in magnitude.
These definitions are equivalent.
Patch by: Jan Vesely
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 197769
|
|
|
|
|
|
|
| |
Patch by: Kai Wasserbäch
Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
llvm-svn: 195898
|
|
|
|
| |
llvm-svn: 195022
|
|
|
|
| |
llvm-svn: 195021
|
|
|
|
|
|
|
| |
This script generates implementations for the entire set of convert_*
functions,
llvm-svn: 192385
|
|
|
|
| |
llvm-svn: 192384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two implementations of nextafter():
1. Using clang's __builtin_nextafter. Clang replaces this builtin with
a call to nextafter which is part of libm. Therefore, this
implementation will only work for targets with an implementation of
libm (e.g. most CPU targets).
2. The other implementation is written in OpenCL C. This function is
known internally as __clc_nextafter and can be used by targets that
don't have access to libm.
llvm-svn: 192383
|
|
|
|
| |
llvm-svn: 192382
|
|
|
|
| |
llvm-svn: 192381
|
|
|
|
|
|
| |
Thanks to Jordon Rose <jordan_rose@apple.com> for pointing this out.
llvm-svn: 190310
|
|
|
|
|
|
|
|
|
| |
We already have a working mul_hi, and the spec gives us the implementation as:
Returns mul_hi(a,b)+c.
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 190211
|
|
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 190201
|
|
|
|
|
| |
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 190059
|
|
|
|
|
| |
Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 190058
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Everything except long/ulong is handled by just casting to the next larger type,
doing the math and then shifting/casting the result.
For 64-bit types, we break the high/low parts of each operand apart, and do
a FOIL-based multiplication.
v2:
Discard the stack-overflow implementation due to copyright concerns.
- The implementation is still FOIL-based, but discards the previous code.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 188684
|
|
|
|
|
|
|
|
|
|
|
|
| |
rhadd = (x+y+1)>>1
Implemented as:
(x>>1) + (y>>1) + ((x&1)|(y&1))
This prevents us having to do assembly addition and overflow detection
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 188477
|
|
|
|
|
|
|
|
|
|
| |
(x + y) >> 1 gets changed to:
(x>>1) + (y>>1) + (x&y&1)
Saves us having to do any llvm assembly and overflow checking in the addition.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 188476
|
|
|
|
| |
llvm-svn: 188131
|
|
|
|
| |
llvm-svn: 188130
|
|
|
|
|
|
|
|
| |
Found in CL 1.1 spec section 6.11.3
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 187200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reduces all vector upsamples down to its scalar components, so probably
not the most efficient thing in the world, but it does what the
spec says it needs to do.
Another possible implementation would be to convert/cast everything as
unsigned if necessary, upsample the input vectors, create the upsampled
value, and then cast back to signed if required.
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
llvm-svn: 186691
|
|
|
|
| |
llvm-svn: 186326
|
|
|
|
|
| |
Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 185839
|
|
|
|
|
|
|
|
|
|
|
| |
libclc was defining and undefing GENTYPE and several other macros with
common names in its header files. This was preventing applications from
defining macros with identical names as command line arguments to the
compiler, because the definitions in the header files were masking the
macros defined as compiler arguements.
Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 185838
|
|
|
|
|
| |
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 185836
|
|
|
|
|
|
|
|
|
|
| |
Assumes that the target supports byte-addressable stores.
Completely unoptimized.
Patch by: Aaron Watry
llvm-svn: 185007
|
|
|
|
|
|
|
|
| |
Should work for all targets and data types. Completely unoptimized.
Patch by: Aaron Watry
llvm-svn: 185006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Squashed commit of the following:
commit a0df0a0e86c55c1bdc0b9c0f5a739e5adef4b056
Author: Aaron Watry <awatry@gmail.com>
Date: Mon Apr 15 18:42:04 2013 -0500
libclc: Rename clz.ll to clz_if.ll to ensure it gets built.
configure.py treats files that have the same name with the .cl and .ll
extensions as overriding eachother.
E.g. If you have clz.cl and clz.ll both specified to be built in the same
SOURCES file, only the first file listed will actually be built.
Since the contents of clz.ll were an interface that is implemented in
clz_impl.ll, rename clz.ll to clz_if.ll to make sure that the interface is
built.
commit 931b62bed05c58f737de625bd415af09571a6a5a
Author: Aaron Watry <awatry@gmail.com>
Date: Sat Apr 13 12:32:54 2013 -0500
libclc: llvm assembly implementation of clz
Untested... currently crashes in the same manner as add_sat.
commit 6ef0b7b0b6d2e5584086b4b9a9243743b2e0538f
Author: Aaron Watry <awatry@gmail.com>
Date: Sat Mar 23 12:35:27 2013 -0500
libclc: Add stub clz builtin
For scalar int/uint, attempt to use the clz llvm builtin.. for all others
return 0 until an actual implementation is finished.
Patch by: Aaron Watry
llvm-svn: 185004
|
|
|
|
|
|
|
|
|
|
|
| |
For any GENTYPE that isn't scalar, we need to implement a mixed
vector/scalar version of clamp/max.
This depends on the min() patches I sent to the list a few minutes ago.
Patch by: Aaron Watry
llvm-svn: 185003
|
|
|
|
|
|
|
|
|
|
| |
Checks if the current GENTYPE is scalar, and if not, then defines a separate
implementation of the function which casts the second arg to vector before
proceeding.
Patch by: Aaron Watry
llvm-svn: 185002
|
|
|
|
|
|
|
|
| |
This doesn't handle the integer cases for min(vector, scalar).
Patch by: Aaron Watry
llvm-svn: 185001
|
|
|
|
|
|
|
|
| |
Much more understandable/readable as a result, and probably more efficient.
Patch by: Aaron Watry
llvm-svn: 184997
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implementation does a lot of bit shifting and masking. Suffice to say,
this is somewhat suboptimal... but it does look to produce correct results
(after the piglit tests were corrected for sign extension issues).
Someone who knows LLVM better than I could re-write this more efficiently.
Patch by: Aaron Watry
llvm-svn: 184996
|
|
|
|
|
|
|
|
| |
Max(x,y) is available for all integer/floating types.
Patch by: Aaron Watry
llvm-svn: 184995
|
|
|
|
|
|
|
|
|
| |
Created under a new shared/ directory for functions which are available for
both integer and floating point types.
Patch by: Aaron Watry
llvm-svn: 184994
|
|
|
|
|
|
|
|
| |
Adds this function for both int and floating data types.
Patch by: Aaron Watry
llvm-svn: 184992
|
|
|
|
| |
llvm-svn: 184988
|
|
|
|
| |
llvm-svn: 184987
|
|
|
|
|
|
| |
static functions are not allowed in OpenCL C
llvm-svn: 184986
|