Because DW_TAG_LLVM_ptrauth_type is not marked as a type, dwarfdump
currently emits a spurious error: DIE has DW_AT_type with incompatible
tag DW_TAG_LLVM_ptrauth_type. This patch fixes that and adds a test.
This change modifies the implementation of the format() function
so that vendor forks committed to building with compilers that
support __attribute__((format)) on non-variadic functions can
check the format() function with it.
Reviewed By: ahatanak
Differential Revision: https://reviews.llvm.org/D132413
rdar://84571523
Summary:
Several loop queries look for a singleton by finding all instances and then
returning whether there is 1 instance or not. This can be improved by
stopping the search after 2 have been found. Introduce generic range
based singleton searches that stop after finding a second value
and use them for these loop queries.
There is no intended functional change other than improved compile-time
efficiency.
Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: Meinersbur (Michael Kruse)
Differential Revision: https://reviews.llvm.org/D136261
This patch adds base 2 logarithm that returns integer result. I initially wanted to name it `!log2`,
but numbers are not permitted in the name. The documentation makes sure to clarify that it is
base 2 since it is not explicit in the operator name.
Differential Revision: https://reviews.llvm.org/D134068
This is not quite NFC because one of the users should
now avoid the DIVREM opcodes too, but I'm not sure
how to test that.
I used the same name as an analysis function in IR
in case we want to expand this to include other
operations.
Another potential use is proposed in D136713.
Small QoL change to allow Predicates to be used in GICombineRule.
Currently only one combine in the AMDGPU backend makes use of it.
The implementation is pretty simple to get started but of course we can expand this later on and optimize predicate checking better if needed.
Reviewed By: dsanders
Differential Revision: https://reviews.llvm.org/D136681
Epilogue loop vectorization is a feature in the vectorize intended to avoid running fully scalar code when the vector length of the main loop turns out to be either longer than the trip count of the actual loop, or with a huge remainder.
In practice, this feature appears to not have been well tuned. I honestly don't think it should be on by default at all, but it definitely shouldn't be on for RISCV. Note that other targets have also disabled it, but they've done so via disabling interleaving - which is, well, completely unrelated - and we don't want to do that for RISCV.
In the near term, many examples I'm seeing have terrible codegen for epilogue vectorization. We are greatly increasing code size for little value at reasonable VLEN values for small types. In the long term, the cases that epilogue vectorization are intended to handle are likely better handled via tail folding on RISCV.
As an aside, I also don't really trust the correctness of epilogue vectorization. The code structure is such that otherwise straight forward changes sometimes break only epilogue vectorization. The reuse of an existing vplan without careful validation opens significant room for nasty bugs. Given how rarely the code is exercised, that is not a good combination.
As such, this patch introduces a TTI hook, and completely disables epilogue vectorization on RISCV.
Differential Revision: https://reviews.llvm.org/D136695
Adds a generic utility for creating anonymous aarch64 pointer blocks
(automatically adding an edge to initialize the pointer if given an
initial target).
Updates the aarch64 GOTTableManager to use the utility when building
GOT entries.
Using the legacy PM for the optimization pipeline was deprecated in 13.0.0.
Following recent changes to remove non-core features of the legacy
PM/optimization pipeline, remove DataFlowSanitizerLegacyPass.
Differential Revision: https://reviews.llvm.org/D124594
This reverts commit bd7949bcd86633bd4203b2ba6f891aea00fce4d1.
Revert this patch since reviwers have different opinions regarding
the approach in post-commit review.
Will open RFC for further discussion.
Differential Revision: https://reviews.llvm.org/D132408
Similar to the EPCEHFrameRegistrar change in c977251ef6f, this allows clients
who have sourced a dylib handle via a side-channel to search that dylib to
find the registration functions.
This patch defaults to the existing behavior in the case where the client does
not specify a handle to use.
SelfExecutorProcessControl no longer requires that handles passed to
lookupSymbols be ones that were previously returned from loadDylib. This brings
SelfExecutorPRocessControl into alignment with SimpleRemoteEPC, which was
updated in 6613f4aff85.
This patch puts the individual target region information attributes into a
struct so that the nested mappings are not needed and passing the information
around is simplified.
Reviewed By: jdoerfert, mikerice
Differential Revision: https://reviews.llvm.org/D136601
getMergedLocation returns a 'line 0' DILocaiton if the two locations
being merged don't perfecly match, even if they are in the same line but
a different column.
This commit adds support to keep the line number if it matches (but only
the column differs). The merged column number is the leftmost between the
two.
Reviewed By: dblaikie, orlando
Differential Revision: https://reviews.llvm.org/D135166
This adds AArch64 TargetParser support to define CPU aliases, and
ports the definition of Grace over to that. This is following up
on D136425.
Differential Revision: https://reviews.llvm.org/D136611
As a continuation of D132034, this switches the QRDMX v8.1a neon
intrinsics over from preprocessor defines to be target-gated. As there
is no "rdma" or "qrdmx" target feature, they use the "v8.1a"
architecture feature directly.
This works well for AArch64, but something needs to be done for Arm at
the same time, as they both use the same header and tablegen emitter.
This patch opts for adding "v8.1a" and all dependant target features to
the Arm TargetParser, similar to what was recently done for AArch64 but
through initFeatureMap when the Architecture is parsed. I attempted to
make the code similar to the AArch64 backend.
Otherwise this is similar to the changes made in D132034.
Differential Revision: https://reviews.llvm.org/D135615
Previously, EPCEHFrameRegistrar always used the
ExecutorProcessControl::loadDylib(nullptr) method to obtain a handle for the
process, but this doesn't work if the registration functions aren't visible in
a standard search of the process (e.g. if the JIT is in a plugin that is loaded
with RTLD_LOCAL).
This patch retains the old behavior by default, but allows clients to supply
their own handle for the library containing the registration functions if they
need to (e.g. to work around limitations like RDLD_LOCAL above, which aren't
expressible within the existing loadDylib / DynamicLibrary APIs).
Updates tpctypes::DylibHandle to be an ExecutorAddr (rather than a uint64_t),
and SimpleExecutorDylibManager to hold and return raw OS handle values (as
ExecutorAddrs) rather than index values into a map of DynamicLibrary instances.
This will allow clients to use EPCGenericDylibManager in contexts where the
existing DynamicLibrary interface is too limited to be used. (e.g. to look up
JIT symbols in a dylib that was loaded with RTLD_LOCAL).
This adds Clang command line support for the NVIDIA Grace CPU [1], which
we would like to target with -mcpu=grace.
Grace is based on the Arm Neoverse V2 CPU [1], which is why, in the
driver, we pass neoverse-v2 to the compiler when grace is requested.
Thus, for now, it's an alias to Neoverse V2.
This adds support for grace in user-facing tool Clang, but not yet the
developer tools like opt and llc, so we probably want to follow up on
this.
[1] https://www.nvidia.com/en-us/data-center/grace-cpu/
Differential Revision: https://reviews.llvm.org/D136425
Recognize when sub-vectors have been split to elements which are used to
build large vector.
This happens when instructions have different vector sizes available.
For example a few arithmetic instruction are required to process all
elements of larger vector that can be stored using one instruction.
Differential Revision: https://reviews.llvm.org/D109242
Recognize when source could have been unmerged to pieces with DstTy
without having to split source to smaller elements
and then merge small elements into DstTy pieces.
This happens when vector was meant to be split to sub-vectors but there
was leftover. At this point artifact combiner have already dealt with
leftover and we can continue to use sub-vectors.
Differential Revision: https://reviews.llvm.org/D109241
Recognize copy that is represented as split of a source register to
elements that were reassembled to another register with the same type.
Differential Revision: https://reviews.llvm.org/D109240
The lack of this attribute (particularly on the load intrinsics)
prevented InstCombine from optimizing away allocas and memcpys
for arrays that could be read directly from rodata.
This now also includes a new test to check the masked load/store
intrinsics have the expected attributes (specifically nocapture).
Differential Revision: https://reviews.llvm.org/D135656
llvm-debuginfo-analyzer is a command line tool that processes debug
info contained in a binary file and produces a debug information
format agnostic “Logical View”, which is a high-level semantic
representation of the debug info, independent of the low-level
format.
The code has been divided into the following patches:
1) Interval tree
2) Driver and documentation
3) Logical elements
4) Locations and ranges
5) Select elements
6) Warning and internal options
7) Compare elements
8) ELF Reader
9) CodeView Reader
Full details:
https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570
This patch:
Compare elements
- Support for logical elements comparison. See '--compare' options.
LVCompare
Reviewed By: psamolysov, probinson
Differential Revision: https://reviews.llvm.org/D125782
llvm-debuginfo-analyzer is a command line tool that processes debug
info contained in a binary file and produces a debug information
format agnostic “Logical View”, which is a high-level semantic
representation of the debug info, independent of the low-level
format.
The code has been divided into the following patches:
1) Interval tree
2) Driver and documentation
3) Logical elements
4) Locations and ranges
5) Select elements
6) Warning and internal options
7) Compare elements
8) ELF Reader
9) CodeView Reader
Full details:
https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570
This patch:
Warning and internal options
- Support for '--warning' options.
- Support for '--internal' options.
Reviewed By: psamolysov, probinson
Differential Revision: https://reviews.llvm.org/D125781
Discarding the init symbol is expected to be uncommon (it represents metadata
in the MaterializationUnit that is relevant to dlopen, and this will not
usually be fully duplicated in some other location), however if a client has
marked an InitSymbol as weak and it is selected to be discarded then we should
keep the data structure consistent.
Handle MULH[US] by normalizing them into newly invented nodes
HexagonISD::(S|U|US)MUL_LOHI. On HVX v60, if only the high part of
SMUL_LOHI is used, use the original MULHS expansion. In all other
cases, expand the full product.
On HVX v62, always expand the full product.
Introduce Hexagon-specific LLVM IR intrinsics for 32x32 multiplication
returning low/high parts.
This doesn't touch objc-arc-contract because that's in the codegen pipeline.
However, this does move its corresponding initialize function into initializeCodegen().
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D135041
The test case 'checkFlexiblePatterns' caused a failure in:
https://lab.llvm.org/buildbot/#/builders/85/builds/11590
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
runtime error: applying zero offset to null pointer
llvm/lib/Support/regengine.inc:151:18
The logical view is traversed and for each logical element a
series of match criterias are applied. One of those criterias
is to match its name or type name to a given pattern.
If the logical element does not have a type (for instance a
'namespace') do not try to use its type name, which is a
empty string as the 'matcher' function receives a null pointer.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D136444
As @python3kgae pointed out we're going to want to assign these IDs
after optimization so that we can remove unused resrouces. This patch
just removes the unused ID value from the frontend metadata, clang code
generation, and updates associated test cases.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D136271
First patch in a series adding MC layer support for SVE2.1.
This patch adds the following feature:
sve2p1
Some of the existing SVE instructions added for SME are now
also available under the sve2p1 feature, which are now guarded
by the HasSVE2p1orSME predicate.
The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09
Differential Revision: https://reviews.llvm.org/D136352
This patch adds the assembly/disassembly for the following instructions:
ADD (to vector): Add replicated single vector to multi-vector with multi-vector result.
SQDMULH (multiple and single vector): Multi-vector signed saturating doubling multiply high by vector.
for 2 and 4 ZA SVE registers.
The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09
It also adds more size for the multiple register tuple:
ZZ_b_mul_r, ZZ_h_mul_r,
ZZZZ_b_mul_r, ZZZZ_h_mul_r,
for 8 bits and 16 bits with 2 and 4 ZA registers.
Depends on: D135468
With a fix for Mips for this test:
llvm/test/MC/Mips/mips64r6/valid.s
Differential Revision: https://reviews.llvm.org/D135563
This implements IR and bitcode support for the memory attribute,
as specified in https://reviews.llvm.org/D135597.
The new attribute is not used for anything yet (and as such, the
old memory attributes are unaffected).
Differential Revision: https://reviews.llvm.org/D135592
llvm-debuginfo-analyzer is a command line tool that processes debug
info contained in a binary file and produces a debug information
format agnostic “Logical View”, which is a high-level semantic
representation of the debug info, independent of the low-level
format.
The code has been divided into the following patches:
1) Interval tree
2) Driver and documentation
3) Logical elements
4) Locations and ranges
5) Select elements
6) Warning and internal options
7) Compare elements
8) ELF Reader
9) CodeView Reader
Full details:
https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570
This patch:
Select elements
- Support for logical elements selection:
LVPatterns
Reviewed By: psamolysov, probinson
Differential Revision: https://reviews.llvm.org/D125780
This is an alternative to fix PR57939 for RISC-V. It definitely
can be argued that the stack temporaries for RISC-V are being created
with an unnecessarily large alignment. But ignoring the alignment
in MachineFrameInfo also seems bad.
Looking at the test update that go with the current ID==0 check,
it was intending to exclude things like the NoAlloc stackid. So I'm
not sure if scalable vectors are intentionally being excluded.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D135913
Move ResourceClass into llvm/Frontend/HLSL/HLSLResource.h so it could be shared between clang and DirectX backend.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D136134
This reverts commit 4c4909703d74883e5cc49edcbd22b783135d2897.
This patch was breaking this test:
llvm/test/MC/Mips/mips64r6/valid.s
I will push again when fixed
