| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 211044
|
| |
|
|
|
|
|
|
| |
Based on clang's stdint.h
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <tom@stellard.net>
llvm-svn: 210933
|
| |
|
|
| |
llvm-svn: 210896
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This fixes the build with with newer LLVM.
llvm-svn: 210867
|
| |
|
|
|
|
| |
Tested with llvm 3.4 and trunk.
llvm-svn: 210825
|
| |
|
|
|
| |
Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 210111
|
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 207685
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
sys::fs_F_Binary has been replaced with sys::fs_F_Text
llvm-svn: 202081
|
| |
|
|
|
|
|
|
| |
These do not import the code specific to nvidiacl
Patch by: Jeroen Ketema
llvm-svn: 201431
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r200413.
This was breaking the build on systems where the python 2.x executable
was called python.
llvm-svn: 201239
|
| |
|
|
|
|
| |
Patch by: Dan Liew
llvm-svn: 200416
|
| |
|
|
|
|
|
|
|
| |
This is necessary for building with Ninja because it does not allow
duplicate rule names.
Patch by: Dan Liew
llvm-svn: 200415
|
| |
|
|
|
|
|
|
|
|
| |
We use ${DESTDIR} syntax now instead of $(DESTDIR) because that syntax
works both is the shell (at least it does for bash) and for make (at
least it does for GNU Make)
Patch By: Dan Liew
llvm-svn: 200414
|
| |
|
|
|
|
| |
Patch by: Dan Liew
llvm-svn: 200413
|
| |
|
|
|
|
|
|
|
| |
Patch by: Udo van den Heuvel
Tom Stellard:
- Added ifdef and error handling
llvm-svn: 199687
|
| |
|
|
|
| |
FIXME: Dragonegg may be updated at non-trivial changes.
llvm-svn: 198274
|
| |
|
|
|
| |
Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 198168
|
| |
|
|
|
| |
Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 198167
|
| |
|
|
|
|
|
|
| |
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: 195023
|
| |
|
|
| |
llvm-svn: 195022
|
| |
|
|
| |
llvm-svn: 195021
|
| |
|
|
|
|
|
|
|
| |
Some function definitions were using _CLC_DECL, which meant that they
weren't being marked as always_inline.
Reviewed-by and Tested-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 193754
|
| |
|
|
|
|
|
|
| |
This will prevent LLVM optimization passes from creating illegal uses
of the barrier() intrinsic (e.g. calling barrier() from a conditional
that is not executed by all threads).
llvm-svn: 193753
|
| |
|
|
|
|
| |
Patch by: Jeroen Ketema
llvm-svn: 193221
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The C++ compiler used to build prepare-builtins
may differ from the llvm/clang for which we are
building libclc.
Use 'clang++' as the default compiler.
Patch by: Jeroen Ketema
llvm-svn: 193220
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
libclc is ABI-agnostic, and $prefix/lib/pkgconfig causes issues
on multilib setups. Using $prefix/share/pkgconfig allows us to reuse
a single libclc build across all system ABIs.
Patch by: Michał Górny
llvm-svn: 190107
|
| |
|
|
|
| |
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
|