|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4 |
|
| #
0ebd4638 |
| 27-Oct-2022 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
clang: Improve errors for DiagnosticInfoResourceLimit
Print source location info and demangle the name, compared
to the default behavior.
Several observations:
1. Specially handling this seems to
clang: Improve errors for DiagnosticInfoResourceLimit
Print source location info and demangle the name, compared
to the default behavior.
Several observations:
1. Specially handling this seems to give source locations
without enabling debug info, and also gives columns compared
to the backend diagnostic.
2. We're duplicating diagnostic effort in DiagnosticInfo
and clang. This feels wrong, but clang can demangle and I guess
have better debug info available? Should clang really have any of this
code? For the purposes of this diagnostic, the important piece
is just reading the source location out of the llvm::Function.
3. lld is not duplicating the same effort as clang with LTO, and
just directly printing the DiagnosticInfo as-is. e.g.
$ clang -fgpu-rdc
lld: error: local memory (480000) exceeds limit (65536) in function '_Z12use_huge_ldsIiEvv'
lld: error: local memory (960000) exceeds limit (65536) in function '_Z12use_huge_ldsIdEvv'
$ clang -fno-gpu-rdc
backend-resource-limit-diagnostics.hip:8:17: error: local memory (480000) exceeds limit (65536) in 'void use_huge_lds<int>()'
__global__ void use_huge_lds() {
^
backend-resource-limit-diagnostics.hip:8:17: error: local memory (960000) exceeds limit (65536) in 'void use_huge_lds<double>()'
2 errors generated when compiling for gfx90a.
4. Backend errors are not observed with -save-temps and -fno-gpu-rdc or -flto,
and the compile incorrectly succeeds.
5. The backend version prints error: <location info>; clang prints <location info>: error:
6. -emit-codegen-only is totally broken for AMDGPU. MC
gets a null target streamer. I do not understand why this
is a thing. This just creates a horrible edge case.
Just work around this by emitting actual code instead of blocking
this patch.
show more ...
|
| #
c62745e1 |
| 27-Oct-2022 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
DiagnosticInfo: Report function location for resource limits
We have some odd redundancy where clang specially handles
the stack size case. If clang prints it, the source location is first
followed
DiagnosticInfo: Report function location for resource limits
We have some odd redundancy where clang specially handles
the stack size case. If clang prints it, the source location is first
followed by "warning". The backend diagnostic, as printed by other tools
puts "warning" first.
show more ...
|
| #
1ad63dc0 |
| 28-Oct-2022 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
clang: Add required target to test
|
| #
7d568cdc |
| 28-Oct-2022 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
AMDGPU: Register a null MC streamer for -emit-codegen-only
For some reason null is a valid MC target, used from clang with
-emit-codegen-only. Previously the target streamer was null,
which was inco
AMDGPU: Register a null MC streamer for -emit-codegen-only
For some reason null is a valid MC target, used from clang with
-emit-codegen-only. Previously the target streamer was null,
which was inconsistently null checked resulting in crashes
if using amdhsa.
show more ...
|