Add targets to emit SPIR-V targeted to Mesa's OpenCL support, using
SPIR-V 1.1.
Substantially based on Dave Airlie's earlier work.
libclc: spirv: remove step/smoothstep apis not defined for SPIR-V
libclc: disable inlines for SPIR-V builds
Reviewed By: jvesely, tstellar, jenatali
Differential Revision: https://reviews.llvm.org/D77589
The SPIR spec states that all OpenCL built-in functions should be
overloadable and mangled, to ensure consistency.
Add the overload attribute to functions which were missing them:
work dimensions, memory barriers and fences, and events.
Reviewed By: tstellar, jenatali
Differential Revision: https://reviews.llvm.org/D82078
Fix FP_ILOGBNAN definition to match the opencl-c-base.h one and
guarantee that FP_ILOGBNAN and FP_ILOGB0 are different. Doing that
implies fixing ilogb() implementation to return the right value.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed By: jvesely
Differential Revision: https://reviews.llvm.org/D83473
Summary:
The llvm libraries depend on the symbols in the system libaries, so
the system libraries need to be added after.
Reviewers: jvesely
Reviewed By: jvesely
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78535
This is required for using the Ninja backend on Windows, as it passes
commands directly to CreateProcess, and does not allow the shell to
interpret them: https://ninja-build.org/manual.html#ref_rule_command
Using the Visual Studio backend is not possible as attempting to create
a static library target comprised entirely of novel languages not known
to the Visual Studio backend built in to CMake's C++ source will
generate nothing at all.
reviewer: jvesely
Differential Revision: https://reviews.llvm.org/D77165
We don't want the regular linker flags for these invocations, since
we're not compiling to the target machine anyway. This fixes things like
'/machine:x64' being unknown when invoked under Windows.
reviewer: jvesely
Differential Revision: https://reviews.llvm.org/D77164
When providing a fake compiler, libclc currently uses 'true' which does
not exist on Windows. Use echo instead as the no-op.
reviewer: jvesely
Differential Revision: https://reviews.llvm.org/D77163
CMake requires library lists on Windows to be split by semi-colons,
rather than the spaces we get from llvm-config. Fix this by a
substitution on Windows.
reviewer: jvesely
Differential Revision: https://reviews.llvm.org/D77162
Fixes a wimpy-mode CTS failure for asin(float).
Passes non-wimpy for both float/double on RX580.
Signed-off-by: Aaron Watry <awatry@gmail.com>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm does not expose -std=c++11 in cxx flags.
gcc-6 switched default from c++98 to c++14
Reviewers: Aaron Watry, Tom Stellard
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 356009
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
llvm-svn: 351731
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Daniel Stone