Instruction G_IS_FPCLASS had an operand that represented floating-point
semantics of its first operand. It allowed types that have the same length,
like `bfloat16` and `half`, to be distinguished. Unfortunately, it is
not sufficient, as other operation still cannot distinguish such types.
Solution of this problem must be more general, so now this operand is removed.
Differential Revision: https://reviews.llvm.org/D138004
This change provides an implementation of the XVentanaCondOps vendor extension. This extension is defined in version 1.0.0 of the VTx-family custom instructions specification (https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf) by Ventana Micro Systems.
In addition to the technical contribution, this change is intended to be a test case for our vendor extension policy.
Once this lands, I plan to use this extension to prototype selection lowering to conditional moves. There's an RVI proposal in flight, and the expectation is that lowering to these and the new RVI instructions is likely to be substantially similar.
Differential Revision: https://reviews.llvm.org/D137350
This patch adds documentation into the advanced builds documentation on
how to use the BOLT caches, including the combinations with the PGO
multistage builds and (Thin)LTO.
Reviewed By: sylvestre.ledru, Amir
Differential Revision: https://reviews.llvm.org/D137899
This patch adds documentation on the AdvancedBuilds page on how to do
PGO builds with (Thin)LTO with the currently undocumented (as far as I
can tell) PGO_INSTRUMENT_LTO option in the Clang PGO caches.
Reviewed By: sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D137898
This patch makes some minor fixups in the PGO section of the advanced
builds documentation in preparation for some future changes. Some minor
formatting and wording changes are included to hopefully make the
documentation more clear.
Reviewed By: sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D137880
More sub-projects will be added to the table once they have been verified
to be buildable in stand-alone mode.
Reviewed By: MaskRay, mgorny
Differential Revision: https://reviews.llvm.org/D123968
GlobalVariable and Function can be available_externally. GlobalAlias is used
similarly. Allowing available_externally is a natural extension and helps
ThinLTO discard GlobalAlias in a non-prevailing COMDAT (see D135427).
For now, available_externally GlobalAlias must point to an
available_externally GlobalValue (not ConstantExpr).
Differential Revision: https://reviews.llvm.org/D137441
This switches everything to use the memory attribute proposed in
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579.
The old argmemonly, inaccessiblememonly and inaccessiblemem_or_argmemonly
attributes are dropped. The readnone, readonly and writeonly attributes
are restricted to parameters only.
The old attributes are auto-upgraded both in bitcode and IR.
The bitcode upgrade is a policy requirement that has to be retained
indefinitely. The IR upgrade is mainly there so it's not necessary
to update all tests using memory attributes in this patch, which
is already large enough. We could drop that part after migrating
tests, or retain it longer term, to make it easier to import IR
from older LLVM versions.
High-level Function/CallBase APIs like doesNotAccessMemory() or
setDoesNotAccessMemory() are mapped transparently to the memory
attribute. Code that directly manipulates attributes (e.g. via
AttributeList) on the other hand needs to switch to working with
the memory attribute instead.
Differential Revision: https://reviews.llvm.org/D135780
Remove the `--src-root` option from the deprecated llvm-config tool.
None of the llvm-project projects use this option anymore. The value
was only meaningful for in-tree use and usually became no longer correct
once LLVM was installed -- either because it was built in a temporary
directory, or installed from a binary package and built on a different
system entirely. Therefore, third-party tools could not have been
relying on it anyway.
The LLVM_SRC_ROOT #define is left intact, as it is used to compute
includedir when llvm-config is used in-source.
Differential Revision: https://reviews.llvm.org/D137144
The Assignment Tracking debug-info feature is outlined in this RFC:
https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir
Add documentation outlining the intent and design.
This adds an initial bit of policy around inclusion of vendor extensions. My intention here is to leave all of the actual decision making to a case by case decision on the regular sync calls, but to spell out some of the pieces we've discussed and (I think) have general agreement on.
Differential Revision: https://reviews.llvm.org/D136968
The pointsToConstantMemory() method returns true only if the memory pointed to
by the memory location is globally invariant. However, the LLVM memory model
also has the semantic notion of *locally-invariant*: memory that is known to be
invariant for the life of the SSA value representing that pointer. The most
common example of this is a pointer argument that is marked readonly noalias,
which the Rust compiler frequently emits.
It'd be desirable for LLVM to treat locally-invariant memory the same way as
globally-invariant memory when it's safe to do so. This patch implements that,
by introducing the concept of a *ModRefInfo mask*. A ModRefInfo mask is a bound
on the Mod/Ref behavior of an instruction that writes to a memory location,
based on the knowledge that the memory is globally-constant memory (in which
case the mask is NoModRef) or locally-constant memory (in which case the mask
is Ref). ModRefInfo values for an instruction can be combined with the
ModRefInfo mask by simply using the & operator. Where appropriate, this patch
has modified uses of pointsToConstantMemory() to instead examine the mask.
The most notable optimization change I noticed with this patch is that now
redundant loads from readonly noalias pointers can be eliminated across calls,
even when the pointer is captured. Internally, before this patch,
AliasAnalysis was assigning Ref to reads from constant memory; now AA can
assign NoModRef, which is a tighter bound.
Differential Revision: https://reviews.llvm.org/D136659
This was previously attempted in 2016 by colinl's D18770, but LLD tests
were missed, which caused the change to be reverted.
Setting --print-imm-hex by default brings llvm-objdump's behavior closer
in line with objdump, and it makes it easier to read addresses and
alignment from the disassembly. It may make non-address immediates
harder to interpret, but it still seems the better default, barring more
context-sensitive base selection logic.
Differential Revision: https://reviews.llvm.org/D136972
Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.
By adding n32 to the DataLayout string, middle end optimizations will consider i32 to be a native type. One known effect of this is enabling LoopStrengthReduce on loops with i32 induction variables. This can be beneficial because C/C++ code often has loops with i32 induction variables due to the use of `int` or `unsigned int`.
If this patch exposes performance issues, those are better addressed by tuning LSR or other passes.
Reviewed By: asb, frasercrmck
Differential Revision: https://reviews.llvm.org/D116735
This brings it in line with recommended practice after the
introduction of sub-operand naming in a538d1f13a, and the
deprecation of positional argument matching in 5351878ba1.
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
Serge Pavlov