The elements in FragmentMap are big objects, use reference can get
better performance, as someone do in line 1912.
Differential Revision: https://reviews.llvm.org/D147126
Since we now handle functions without a body as well, we can't just use
getHasBody() anymore. Funtions that haven't been defined yet are those
that don't have a body *and* aren't valid.
Also, just pass the information about whether the Function has a body or
not along from the FunctionDecl.
Differential Revision: https://reviews.llvm.org/D141591
The amount to shift should be specified by the int type not a 32-bit integer
type.
This patch change the functions for 128-bit shifts in compiler-rt the same way
as was done for 64-bit shifts in D78662.
The README.txt is updated with the shift builtins signatures from this patch and D78662.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D146960
Value::setNameImpl() is used both to set and reset name of the value.
In destructor of Function all arguments get reset their names
(see Function::clearArguments()). If the arguments had their names set (e.g.
when the function was created with LLVMContex::DiscardValueNames == true)
then their ValueName entries referred by the function's symbol table must be
destructed. They are not destructed if LLVMContex::DiscardValueNames is set to
false because of the fast path in Value::setNameImpl(). See the new test cases
that demonstrate the problem. Without the fix they both crash in the function's
destructor.
In Value::setNameImpl() this patch narrows down the fast path return for
DiscardValueNames == true to allow destruction of ValueName entries if any.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D143487
WebAssembly tries to cast an `undef` to `CosntantSDNode` during `LowerAccessVectorElement`.
These operations will trigger an assertion error in cast.
To avoid this issue, we prevent casting, and abort the lowering operation.
A unit test is also included.
This patch fixes [pr61828](https://github.com/llvm/llvm-project/issues/61828)
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D147198
Constants in BUILD_VECTOR may be down cast into a smaller value that fits LaneBits, i.e., the bit width of elements in the vector.
This cast didn't consider 2^N where it would be cast into -2^N, which still doesn't fit into LaneBits after casting.
This will cause an assertion in later legalization.
2^N should be cast into 0, and this patch reflects such behavior.
This patch also includes a test to reflect the fix.
This patch fixes [issue 61780](https://github.com/llvm/llvm-project/issues/61780)
Related patch: https://reviews.llvm.org/D108669
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D147208
The name "coords" should be used for the complete tuple of Dimension-/Level-many "crd" values associated with a single element. Whereas the name "coordinates" should only be used for collections of "crd" values which span several elements (e.g., the tensor's coordinates buffer for a single level).
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D147291
Values of ArgKind are used (as naked constants) also in IntrinsicEmitter.
They can be dissolved to move their logic to Intrinsics.td.
Differential Revision: https://reviews.llvm.org/D145873
This is necessary in order for type equality checking, for example
across redeclarations, to require constraints to match. This is also a
prerequisite for including the constraints in manglings.
In passing, fix a bug where TemplateArgument::Profile would produce the
same profile for two structurally different template names, which caused
this change to re-expose the crash previously addressed by D133072,
which it turns out had not quite addressed all problematic cases.
This follows C++ [temp.over.link]/6, which says that constraints are not
part of what determines whether two template parameters are equivalent.
This allows templates that have different constraints on nested template
template parameters to be ordered by their constraints.
constrained friend".
When a friend declaration has a requires-clause, and either it's a
non-template function or it's a function template whose requires-clause
depends on an enclosing template parameter, it is member-like for the
purpose of redeclaration checking. Specifically, the lexically enclosing
class becomes part of its signature, so it can only be redeclared by
another declaration within the same class. In this change, we call such
functions "member-like constrained friends".
No functional change intended.
I only added Zicsr to CPUs that didn't already have an implication
through the F extension.
As far as I could tell from searching Rocket and Syntacore repositories,
all the CPUs support these instructions.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D147261
StartIndexes[0] Tells exactly which source element is in element 0,
the even source. Nothing needs to be swapped.
Since we're dealing with power of 2 vector lengths, StartIndexes[0]
is almost always even so the condition here was never true. The
exception is when we're interleaving two 1 element vectors. In that
case StartIndexes[0] could be 1.
We recently hit a failure from this on a pulldown. I don't have
the reduced reproducer yet and my naive attempts at making an
interleave of 1 element vectors produces a slideup instead so don't
go through this path.
Reviewed By: luke
Differential Revision: https://reviews.llvm.org/D147268
New versions I2.1, F2.2, D2.2 A2.1
Make F and Zfinx imply Zicsr.
Make G imply Zifencei.
This should have no impact to generated code. We have no plans to require Zicsr/Zifencei extension to be explicitly enabled to use Zicsr/Zifencei instructions in assembly.
See https://reviews.llvm.org/D147183 for documentation regarding what version specification we implement.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D147179
* Fix an issue where temporaries initialized via parenthesized aggregate
initialization don't get destroyed.
* Fix an issue where aggregate initialization omits calls to class
members' move constructors after a TreeTransform. This occurs because
the CXXConstructExpr wrapping the call to the move constructor gets
unboxed during a TreeTransform of the wrapping FunctionalCastExpr (as with a
InitListExpr), but unlike InitListExpr, we dont reperform the
InitializationSequence for the list's expressions to regenerate the
CXXConstructExpr. This patch fixes this bug by treating
CXXParenListInitExpr identically to InitListExpr in this regard.
Fixes#61145
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D146465
Previously, the genCast function generates arith.trunci for converting f32 to
i32. Fix the function to use mlir::convertScalarToDtype to correctly handle
conversion cases beyond index casting.
Add a test case for codegen the sparse_tensor.convert op.
Reviewed By: aartbik, Peiming, wrengr
Differential Revision: https://reviews.llvm.org/D147272
There are cases where stub library processing can trigger new exports
which might require them to be included at LTO time.
Specifically `processStubLibraries` marks symbols as `forceExports`
which even effect the LTO process.
And since the LTO process can generate new undefined symbols
(specifically libcall function) we need to also process the stub
libraries after LTO.
Differential Revision: https://reviews.llvm.org/D147190
Previously, distinct lambdas would get merged, and multiple definitions
of the same lambda would not get merged, because we attempted to
identify lambdas by their ordinal position within their lexical
DeclContext. This failed for lambdas within namespace-scope variables
and within variable templates, where the lexical position in the context
containing the variable didn't uniquely identify the lambda.
In this patch, we instead identify lambda closure types by index within
their context declaration, which does uniquely identify them in a way
that's consistent across modules.
This change causes a deserialization cycle between the type of a
variable with deduced type and a lambda appearing as the initializer of
the variable -- reading the variable's type requires reading and merging
the lambda, and reading the lambda requires reading and merging the
variable. This is addressed by deferring loading the deduced type of a
variable until after we finish recursive deserialization.
This also exposes a pre-existing subtle issue where loading a
variable declaration would trigger immediate loading of its initializer,
which could recursively refer back to properties of the variable. This
particularly causes problems if the initializer contains a
lambda-expression, but can be problematic in general. That is addressed
by switching to lazily loading the initializers of variables rather than
always loading them with the variable declaration. As well as fixing a
deserialization cycle, that should improve laziness of deserialization
in general.
LambdaDefinitionData had 63 spare bits in it, presumably caused by an
off-by-one-error in some previous change. This change claims 32 of those bits
as a counter for the lambda within its context. We could probably move the
numbering to separate storage, like we do for the device-side mangling number,
to optimize the likely-common case where all three numbers (host-side mangling
number, device-side mangling number, and index within the context declaration)
are zero, but that's not done in this change.
Fixes#60985.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D145737
Since `RK::Recs` is sorted by character order, anonymous defs will be
enumerated like this;
- anonymous_0
- anonymous_1
- anonymous_10
- anonymous_100
- anonymous_1000
- ...
- anonymous_99
- anonymous_990
- ...
- anonymous_999
Some records around each gap might be wrapped around along increase or
decrease of records in middle. Then output order of anonymous defs
might be changed.
Numeric sort is expected to prevent such wrap-arounds.
This can be implemented with `StringRef::compare_numeric()`.
- ...
- anonymous_99
- anonymous_100
- ...
- anonymous_999
- anonymous_1000
- ...
See also discussions in D145874.
Differential Revision: https://reviews.llvm.org/D145874
Following the work done by @jdevlieghere in D143690, this changes how Clang module build
events are emitted.
Instead of one Progress event per module being built, a single Progress event is used to
encompass all modules, and each module build is sent as an `Increment` update.
Differential Revision: https://reviews.llvm.org/D147248
Currently when in -CC mode when processing a function like macro
ReadMacroParameterList(...) does not handle the case where there is a comment
embedded in the parameter-list.
Instead of using LexUnexpandedToken(...) I switched to using
LexUnexpandedNonComment(...) which eats comments while lexing.
Fixes: https://github.com/llvm/llvm-project/issues/60887
Differential Revision: https://reviews.llvm.org/D144511
I ran into issues with linking downstream language plugin to liblldb in
debug builds, hitting link time errors of form:
```
undefined reference to `vtable for lldb_private::<Insert LLDB class here>'
```
Anchoring the vtable to the .cpp files resolved those issues.
Differential Revision: https://reviews.llvm.org/D147252
This directly matches the codegen for xventanacondops with vt.maskcn =>
czero.nez and vt.maskc => czero.eqz. An additional difference is that
zicond is available on RV32 in addition to RV64 (xventanacondops is RV64
only).
Differential Revision: https://reviews.llvm.org/D147147
This reverts commit c5c6781428a70d1fffd00a256a237cbf5a3ccfd3.
This likely broke the android sanitizer builders prior because it
accidentally enabled interceptors for android, which they don't use, so
c-allocation functions like malloc would go through hwasan.
This reland adds the HWASAN_WITH_INTERCEPTORS check.
Table A.6 in the RISC-V ISA Manual indicates that sequentially
consistent atomic ops that have a matching instruction should be mapped
to `amo<op>.{w|d}.aqrl`. But sequentially consistent operations that are
mapped to lr/sc should produce `loop: lr.{w|d}.aqrl; <op>; sc.{w|d}.rl;
bnez loop`. Previously, LLVM produced an `sc.{w|d}.aqrl` which was
stronger than necessary. This patch adjusts the relevant logic so that a
`sc.{w|d}.rl` is produced.
Differential Revision: https://reviews.llvm.org/D146933
Previously, we inconsistently defined whether a feature was unavailable
on a given deployment target. We would have availability attributes for
all features, but only some features had the equivalent of a _HAS_NO_FOO
macro in the form of the DISABLE_FTM___foo macros. Instead, systematically
define a _HAS_NO_FOO macro, which makes it easier to understand how to
add availability markup for a new platform.
Differential Revision: https://reviews.llvm.org/D147226
We introduced the implementation of supporting asynchronous routines with depend objects specified in Version 5.1 of the OpenMP Application Programming Interface. In brief, these routines omp_target_memcpy_async and omp_target_memcpy_rect_async perform asynchronous (nonblocking) memory copies between any
combination of host and device pointers. The basic idea is to create the implicit tasks to carry the memory copy calls and handle dependencies specified by depend objects. The implicit tasks are executed via hidden helper thread in OpenMP runtime.
Reviewed By: jdoerfert, tianshilei1992
Committed By: jplehr
Differential Revision: https://reviews.llvm.org/D136103
This matches the handling for integer IVs. I left the non-opaque cases alone, mostly because they're largely irrelevant today.
This doesn't actually make much difference in vectorization right now as we immediately fail on aliasing checks (which also bail on non-constant strides). Slightly suprisingly, it's the case which *do* need runtime checks which work after this patch as they don't use the same dependency analysis path.
This will also enable non-constant stride pointer recurrences for other consumers. I've auditted said code, and don't see any obvious issues.
Due to a change in the APIs used to determine what instructions can be outlined, the check for label outling was never hit. Instead, all labels were considered invisible, which is the opposite of the intended behavior and causes obscure crashes down the line. We now replicate the original behavior more closely, with explicit checks for known-good and known-bad instruction types.
Reviewed by: paquette
Differential Revision: https://reviews.llvm.org/D147178
+load methods are static initializers and treated specially by the
runtime: all +load methods for a class & its categories are called when
loading that class, unlike regular methods where only one definition
will get called per message. Thus, there is no need to check for
duplicates.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D147230
We were previously assuming that to hold, but it appears that `swiftc`
may generate classes that link against `__objc_empty_cache` for their
rodata pointer.
This should allow us to re-land {D142916} (as a stack).
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D147229
This implements ld64's checks for duplicate method names in categories &
classes.
In addition, this sets us up for implementing Obj-C category merging.
This diff handles the most of the parsing work; what's left is rewriting
those category / class structures.
Numbers for chromium_framework:
base diff difference (95% CI)
sys_time 2.182 ± 0.027 2.200 ± 0.047 [ -0.2% .. +1.8%]
user_time 6.451 ± 0.034 6.479 ± 0.062 [ -0.0% .. +0.9%]
wall_time 6.841 ± 0.048 6.885 ± 0.105 [ -0.1% .. +1.4%]
samples 33 22
Fixes https://github.com/llvm/llvm-project/issues/54912.
Issues seen with the previous land will be fixed in the next commit.
Reviewed By: #lld-macho, thevinster, oontvoo
Differential Revision: https://reviews.llvm.org/D142916
