This test is no longer necessary as it is a subset of:
llvm/test/Analysis/CostModel/AArch64/shuffle-load.ll
Differential Revision: https://reviews.llvm.org/D124456
Just clone all the virtual registers instead of looking for def
operands. This preserves the register values used, simplifying the
rest of the code. This avoids needing to expose the register map to
target code.
Previously the specific values used for fixed frame indexes was in
reverse order in the cloned function from the original, and a map was
used to adjust all frame indexes to the potentially new values. Insert
the fixed objects in reverse to avoid this. This simplifies other
code, since now we don't need to track down all frame indexes. This
will allow targets that store frame indexes in MachineFunctionInfo to
simply copy the values.
Note this isn't directly observable in the test since the resulting
MIR print/parse can shuffle the IDs around (in particular the final
serialization implicitly strips out dead objects).
This change borrows the ideas from `computeExpanded/CollapsedLayoutMap`
and computes the dynamic strides at runtime for the memref descriptors.
Differential Revision: https://reviews.llvm.org/D124001
A recent change assumed that the native C++ "long double" maps to
a Fortran data type; but this turns out to not be true for ppc64le,
which uses "double-double" for "long double".
This is a quick patch to get the ppc64le flang build bot back up.
A better fix that either uses HostTypeExists<> or replaces "long double"
with "ieee128_t" (or some other solution) is expected to follow soon.
Differential Revision: https://reviews.llvm.org/D124423
A struct like { float a; int :0; } should per the SystemZ ABI be passed in a
GPR, but to match a bug in GCC it has been passed in an FPR (see 759449c).
GCC has now corrected the C++ ABI for this case, and this patch for clang
follows suit.
Reviewed By: Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D122388
Switch statements that cover all cases should not have a `default`
case. When a switch covers all cases and includes a `default` case,
clang emits a diagnostic. Omitting the `default` case allows the
compiler to instead emit a diagnostic on unhandled enum values.
This change removes default cases from all the places that they
shouldn't be, and adds a missing enum case for one switch statement
that wasn't covering all values.
Summary:
A previous patch updated the path searching in the linker wrapper. I
made an error and caused `lld`, which is necessary to link AMDGPU
images, to not be found on some systems. This patch fixes this by
correctly searching that linker-wrapper's binary path first again.
This was reverted twice, in 987cd7c3ed and 13815e8cbf. The latter
stemed from not accounting for rare register classes in a pre-allocated
array, and the former from an array not being completely initialized,
leading to asan complaining.
This reorganizes the code as a preparation for D123865:
* Use more descriptive names for variables
* Simplify a condition by use an already calculated value
for `MaxPeelCount`
* Remove a duplicate log entry
* Report basic values for loop costs
Differential Revision: https://reviews.llvm.org/D124388
Fix the misleading diag msg as the option is ignored for a particular
offload arch only.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D124396
Some tests failed for NVPTX target, but it seems that NVPTX will be
fixed and the tests will pass. So, just mark the tests as XFAIL
Differential Revision: https://reviews.llvm.org/D124125
Some generic tests are not supported by the nvptx now. Moreover, they
are no plans to fix the tested features in nvptx. So, suggest to mark
them as UNSUPPORTED
Differential Revision: https://reviews.llvm.org/D123928
Introduced by 23a5090c6, this style option marker indicated
'clang-format 9', though its respective option was available in
an earlier release.
Differential Revision: https://reviews.llvm.org/D123299
Commit 5c90eca added some analyzer option checking, but a typo meant
it was redundantly checking PS4 and not adding checking for PS5.
With the test corrected, it identified the necessary driver updates,
added in this commit.
Add support for concepts and requires expression in the clang index.
Genarate USRs for concepts.
Also change how `RecursiveASTVisitor` handles return type requirement in
requires expressions. The new code unpacks the synthetic template parameter
list used for storing the actual expression. This simplifies
implementation of the indexing. No code seems to depend on the original
traversal anyway and the synthesized template parameter list is easily
accessible from inside the requires expression if needed.
Add tests in the clangd codebase.
Fixes https://github.com/clangd/clangd/issues/1103.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D124441
See the discussion on D123319. Default calling convention on Windows32
bit is to have 'this-call' for member functions, so add a wildcard to
take care of that.
Also, one of the FileCheck 'match' flags was incorrect, so fix that too.
Since the size of most of SCC's is 1, the PriorityInlineOrder would not change the inline
order in SCC inliner.
Reviewed By: kazu
Differential Revision: https://reviews.llvm.org/D123608
At the moment, unfeasible default destinations are not handled properly
in removeNonFeasibleEdges. So far, only unfeasible cases are removed,
but later code expects unreachable blocks to have no predecessors.
This is causing the crash reported in PR49573.
If the default destination is unfeasible it won't be executed. Create
a new unreachable block on demand and use that as default
destination.
Note that at the moment this only is relevant for cases where
resolvedUndefsIn marks the first case as executable. Regular switch
handling has a FIXME/TODO to support determining whether the default
case is feasible or not.
Fixes#48917.
Differential Revision: https://reviews.llvm.org/D113497
Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.
Just pass in a buffer (if any) to the constructor. Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.
That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.
The buffer reset member function is never used, and is deleted.
The original buffer initialization code would return a failure code if
that first malloc failed. Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.
But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122604
Apply this in add_compiler_rt_runtime instead of manually adding it
to the individual projects. This applies the option on more
parts of compiler-rt than before, but should ideally not make any
difference assuming the other runtimes that lacked the option
also were C11 compatible.
Not marking this as required, to match the existing behaviour (where
`-std=c11` was added only if supported by the compiler).
This was suggested during the review of D110005.
Differential Revision: https://reviews.llvm.org/D124343
Don't check whether an input of BDV can be pruned if the input
is the BDV itself. BDV is present in the states map, so in case
the input is the BDV itself, we'd return false. So explicitly check this case.
Differential Revision: https://reviews.llvm.org/D123846
llvm-gsymutil has an implementation of AddressRange and AddressRanges
classes. That implementation might be reused in other parts of llvm.
This patch moves AddressRange and AddressRanges classes into llvm/ADT.
Differential Revision: https://reviews.llvm.org/D124350
The vector register spills have no dependency with
SILowerSGPRSpills pass anymore. The entire handling
has been moved to PrologEpilogInserter with D55301.
Instead of report fatal error, this patch emit error message and exit
when shapes are not pre-defined. This would cause the compiling fail but
not crash.
Differential Revision: https://reviews.llvm.org/D124342
In the following example:
int va_list_get_int(va_list *va) {
return va_arg(*va, int); // FP
}
The `*va` expression will be something like `Element{SymRegion{va}, 0, va_list}`.
We use `ElementRegions` for representing the result of the dereference.
In this case, the `IsSymbolic` was set to `false` in the
`getVAListAsRegion()`.
Hence, before checking if the memregion is a SymRegion, we should take
the base of that region.
Analogously to the previous example, one can craft other cases:
struct MyVaList {
va_list l;
};
int va_list_get_int(struct MyVaList va) {
return va_arg(va.l, int); // FP
}
But it would also work if the `va_list` would be in the base or derived
part of a class. `ObjCIvarRegions` are likely also susceptible.
I'm not explicitly demonstrating these cases.
PS: Check the `MemRegion::getBaseRegion()` definition.
Fixes#55009
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D124239
This change introduces a new intrinsic, `llvm.is.fpclass`, which checks
if the provided floating-point number belongs to any of the the specified
value classes. The intrinsic implements the checks made by C standard
library functions `isnan`, `isinf`, `isfinite`, `isnormal`, `issubnormal`,
`issignaling` and corresponding IEEE-754 operations.
The primary motivation for this intrinsic is the support of strict FP
mode. In this mode using compare instructions or other FP operations is
not possible, because if the value is a signaling NaN, floating-point
exception `Invalid` is raised, but the aforementioned functions must
never raise exceptions.
Currently there are two solutions for this problem, both are
implemented partially. One of them is using integer operations to
implement the check. It was implemented in https://reviews.llvm.org/D95948
for `isnan`. It solves the problem of exceptions, but offers one
solution for all targets, although some can do the check in more
efficient way.
The other, implemented in https://reviews.llvm.org/D96568, introduced a
hook 'clang::TargetCodeGenInfo::testFPKind', which injects a target
specific code into IR to implement `isnan` and some other functions. It is
convenient for targets that have dedicated instruction to determine FP data
class. However using target-specific intrinsic complicates analysis and can
prevent some optimizations.
A special intrinsic for value class checks allows representing data class
tests with enough flexibility. During IR transformations it represents the
check in target-independent way and saves it from undesired transformations.
In the instruction selector it allows efficient lowering depending on the
used target and mode.
This implementation is an extended variant of `llvm.isnan` introduced
in https://reviews.llvm.org/D104854. It is limited to minimal intrinsic
support. Target-specific treatment will be implemented in separate
patches.
Differential Revision: https://reviews.llvm.org/D112025
This patch provides the response and reporting guides for Code of Conduct reports. It also removes the word draft from all the documents,
adds information about the CoC committee, and a place to put transparency reports. A post will also be made on Discourse to provide more details about the history of the code of conduct, this patch, and next steps. Please see that post for full details. I will put a link below once I have it.
Reviewed By: aaron.ballman, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D122937
TraceInstructionDumper::DumpInstructions was becoming too big, so I'm
refactoring it into smaller functions. I also made some static methods proper
instance methods to simplify calls. Other minor improvements are also done.
Differential Revision: https://reviews.llvm.org/D124064
Vasileios Porpodas