usage information in JSON to a file
Each line in the file is a JSON object that has the name of the main
source file followed by the list of system header files included
directly or indirectly from that file.
For example:
{"source":"/tmp/foo.c",
"includes":["/usr/include/stdio.h", "/usr/include/stdlib.h"]}
To reduce the amount of data written to the file, only the system
headers that are directly included from a non-system header file are
recorded.
In order to emit the header information in JSON, it is necessary to set
the following environment variables:
CC_PRINT_HEADERS_FORMAT=json CC_PRINT_HEADERS_FILTERING=only-direct-system
The following combination is equivalent to setting CC_PRINT_HEADERS=1:
CC_PRINT_HEADERS_FORMAT=textual CC_PRINT_HEADERS_FILTERING=none
Differential Revision: https://reviews.llvm.org/D137996
This covers more options for CSE. It also ensures that two operations
that have same operands but different regions to begin with, but same
regions after `simplifyRegions`, don't get both added to the list of
`knownValues`.
Fixes#59135
Differential Revision: https://reviews.llvm.org/D139490
Any hwasan tag checking done through runtime calls like __hwasan_mem* or
__hwasan_load/store* currently raise a sigtrap on a tag mismatch. Hwasan
dumps as much information it knows on the tag mismatch by placing
important values in specific registers before the brk and encoding the
access information in the optional argument supplied to the brk. If the
platform hwasan runs on uses signal handlers, then users can see the
typical pretty hwasan error report, but Fuchsia doesn't use signal
handlers, so it's left up to the platform exception handler to print all
this encoded information.
This patch attempts to enter the regular error reporting path via
HandleTagMismatch if a new macro CAN_GET_REGISTERS is set. For now this
is only defined for Fuchsia + aarch64, but can be expanded for other
platforms.
Differential Revision: https://reviews.llvm.org/D139377
The goal is to make the naming of the future `_extended` ops more
consistent. With unsigned addition, the carry value/flag and overflow
bit are the same, but this is not true when it comes to signed addition.
Also rename the second result from `carry` to `overflow`.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D139569
Renames the current lowering scheme to "module" and introduces two new
ones, "kernel" and "table", plus a "hybrid" that chooses between those three
on a per-variable basis.
Unit tests are set up to pass with the default lowering of "module" or "hybrid"
with this patch defaulting to "module", which will be a less dramatic codegen
change relative to the current. This reflects the sparsity of test coverage for
the table lowering method. Hybrid is better than module in every respect and
will be default in a subsequent patch.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D139433
At the moment, they are a part of EmptyOp::getCanonicalizationPatterns. When
extract_slice(tensor.empty) is rewritten as a new tensor.empty, it could
happen that we end up with two tensor.empty ops, since the original
tensor.empty can have two users. After bufferization such cases result in two
allocations.
Differential Revision: https://reviews.llvm.org/D139308
Define the same kmpc_atomic functions for arm and arm64 that are defined for x86 and x64.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D139139
DXIL shader bitcode is hashed and the hash is placed into the final
output object file in its own data part.
This change modifies the DXContainerGlobals pass to compute the shader
hash (just an MD5 of the bitcode) and put the shader hash data into a
global for the HASH part.
This also sets the hash flag as appropriate for if the hashed shader
contained debug information. There is additional handling required to
get debug information in shaders working correctly with our tooling,
but that will be addressed in subsequent patches.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D139357
