Summary:
This block of code wraps around the standard C library includes.
However, the order C library includes are presented is actually
important. If they are visible before the `libc++` headers then it will
cause errors. This patch simply moves the logic to just before it is
normally done. A more optimal solution would be to put this in the
toolchain, however doing it correctly would require knowing the
offloading kind and that would require rewriting the function signature
in all 30 or so ToolChains.
Removed foo-registered-target constraints from a bunch of tests, because
mostly the driver doesn't need to have a target availabile. I ran
check-clang-driver using a build with only the XCore target, and these
all passed.
There are ~50 tests that still have foo-registered-target, and it looks
like most of them are either doing codegen when they don't need to, or
don't really belong in the Driver tests. But that's a task for another
day.
Summary:
Recent changes to the `libc` project caused the headers to be installed
to `include/<triple>` for the GPU and the libraries to be in
`lib/<triple>`. This means we should automatically append these search
paths so they can be found by default. This allows the following to work
targeting AMDGPU.
```shell
$ clang foo.c -flto -mcpu=native --target=amdgcn-amd-amdhsa -lc <install>/lib/amdgcn-amd-amdhsa/crt1.o
$ amdhsa-loader a.out
```
For the in-progress GPU `libc` project we are relying on overlay headers to
handle the interfacing between the `libc` project and the host `libc`.
We need this to be included on both the host and device so they agree
one what is present on the device, otherwise we will end up with random
errors. For whatever reason this was not being included on the host
although it previously worked. This patch ensures that it's included on
both.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D157438
This is an alternate approach to the patches proposed in D153897 and
D153794. Rather than exporting a single header that can be included on
the GPU in all circumstances, this patch chooses to instead generate a
separate set of headers that only provides the declarations. This can
then be used by external tooling to set up what's on the GPU. This
leaves room for header hacks for offloading languages without needing to
worry about the `libc` implementation.
Currently this generates a set of headers that only contain the
declarations. These will then be installed to a new clang resource
directory called `llvm_libc_wrappers/` which will house the shim code.
We can then automaticlaly include this from `clang` when offloading to
wrap around the headers while specifying what's on the GPU.
Reviewed By: jdoerfert, JonChesterfield
Differential Revision: https://reviews.llvm.org/D154036
This reverts commit a4a26374aa11d48ac6bf65c78c2aaf8f16414287.
This was causing some problems with the CPU build and CUDA buildbot.
Revert until I can figure out what those issues are and fix them. I
believe it is just some CMake.
This is an alternate approach to the patches proposed in D153897 and
D153794. Rather than exporting a single header that can be included on
the GPU in all circumstances, this patch chooses to instead generate a
separate set of headers that only provides the declarations. This can
then be used by external tooling to set up what's on the GPU. This
leaves room for header hacks for offloading languages without needing to
worry about the `libc` implementation.
Currently this generates a set of headers that only contain the
declarations. These will then be installed to a new clang resource
directory called `llvm_libc_wrappers/` which will house the shim code.
We can then automaticlaly include this from `clang` when offloading to
wrap around the headers while specifying what's on the GPU.
Reviewed By: jdoerfert, JonChesterfield
Differential Revision: https://reviews.llvm.org/D154036
There is currently work to support basic `libc` functionality on the
GPU. Some basic information about the projects can be found at
https://libc.llvm.org/gpu_mode.html. Typically, including the system
headers on the GPU will result in an error. For this reason the LLVM
`libc` project will generate its own headers that can be used with the
GPU.
The problem is that these headers will use the same name as the system headers.
For that reason, D146970 places it in the `llvm-libc` subfolder. In order to
still pick these files up, this patch adds changes in clang to default to
searching this directory when targeting the GPU. This lets offloading languages
such as OpenMP use the system `string.h` when compiling for the host and then
the LLVM libc `string.h` when targeting the GPU.
Depends on D146970
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D146973
