Before this patch /summary was crashing with some .PCH.OBJ files, because tpiMap[srcIdx++] was reading at the wrong location. When the TpiSource depends on a .PCH.OBJ file, the types should be offset by the previously merged PCH.OBJ set of indices.
Differential Revision: https://reviews.llvm.org/D88678
This seems to fail on ubuntu 18.04.5 with Clang 9 due to:
Error output:
error: Couldn't lookup symbols:
std::__1::default_delete<int>::operator()(int) const
The script's shebang wants Python 3, so we use FindPython3. The
original code didn't work when an unversioned python was not available.
This is explicitly allowed in PEP 394. ("Distributors may choose to set
the behavior of the python command as follows: python2, python3, not
provide python command, allow python to be configurable by an end user
or a system administrator.")
Also I think it's actually required, so let the configuration fail if we
can't find it.
Lastly remove the shebang, since the script is only run via interpreter
and doesn't have the executable bit set anyway.
Reviewed By: jvesely
Differential Revision: https://reviews.llvm.org/D88366
Truncating to v8i8 is a case where we want to split the source but also generate
intermediate truncates to reduce the size of the source vector before truncating
down to v8i8. This implements the same strategy as what SelectionDAG does, but
I'm not certain where if anywhere in generic code it should live.
Use it for legalization of v8s8 = G_ICMP v8s32.
Differential Revision: https://reviews.llvm.org/D88191
Fix premature decision in the presence of type-dependent expression
operands on whether AltiVec vector initializations from single
expressions are "splat" operations.
Verify that the instantiation is able to determine the correct cast
semantics for both the scalar type and the vector type case.
Note that, because the change only affects the single-expression
case (and the target type is an AltiVec-style vector type), the
replacement of a parenthesized list with a parenthesized expression
does not change the semantics of the program in a program-observable
manner.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D88526
Add Thread Local Storage support for the 34 bit relocation R_PPC64_GOT_TLSGD_PCREL34 used in General Dynamic.
The compiler will produce code that looks like:
```
pla r3, x@got@tlsgd@pcrel R_PPC64_GOT_TLSGD_PCREL34
bl __tls_get_addr@notoc(x@tlsgd) R_PPC64_TLSGD
R_PPC64_REL24_NOTOC
```
LLD should be able to correctly compute the relocation for R_PPC64_GOT_TLSGD_PCREL34 as well as do the following two relaxations where possible:
General Dynamic to Local Exec:
```
paddi r3, r13, x@tprel
nop
```
and General Dynamic to Initial Exec:
```
pld r3, x@got@tprel@pcrel
add r3, r3, r13
```
Note:
This patch adds support for the PC Relative (no TOC) version of General Dynamic on top of the existing support for the TOC version of General Dynamic.
The ABI does not provide any way to tell by looking only at the relocation `R_PPC64_TLSGD` when it is being used in a TOC instruction sequence or and when it is being used in a no TOC sequence. The TOC sequence should always be 4 byte aligned. This patch adds one to the offset of the relocation when it is being used in a no TOC sequence. In this way LLD can tell by looking at the alignment of the offset of `R_PPC64_TLSGD` whether or not it is being used as part of a TOC or no TOC sequence.
Reviewed By: NeHuang, sfertile, MaskRay
Differential Revision: https://reviews.llvm.org/D87318
We prefer autodetection here to avoid persisting this configuration
in the generated __config header which is shared across targets.
Differential Revision: https://reviews.llvm.org/D88694
This should fix the test failures on the clang win64 bot:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/18830
It has been red since Sept 23-ish.
This was subtle to debug. Windows has 'find' and 'sort' utilities in
C:\Windows\system32, but they don't support all the same flags as the
coreutils programs. I configured the buildbot above with Python 2.7
64-bit (hey, it was set up in 2016). When I installed git for Windows, I
opted to add all the Unix utilities that come with git to the system
PATH. This is *almost* enough to make the LLVM tests pass, but not
quite, because if you use the system PATH, the Windows version of find
and sort come first, but the tests that use diff, cmp, etc, will all
pass. So only a handful of tests will fail, and with cryptic error
messages.
The code changed in this CL doesn't work with Python 2. Before
Python 3.2, the winreg.OpenKey function did not accept the `access=`
keyword argument, the caller was required to pass an unused `reserved`
positional argument of 0. The try/except/pass around the OpenKey
operation masked this usage error in Python 2.
Further, the result of the registry operation has to be converted from
unicode to add it to the environment, but that was incidental.
When replacing X == Y ? f(X) : Z with X == Y ? f(Y) : Z, make sure
that Y cannot be undef. If it may be undef, we might end up picking
a different value for undef in the comparison and the select
operand.
This is a partial revert of D62155. Rather than copying libc++ headers
into the build directory to be later overwritten by the final headers,
use -isystem flag to access libc++ headers during CMake checks. This
should address the occasional flake we've seen, especially on Windows
builders where CMake fails to overwrite __config with the final version.
Differential Revision: https://reviews.llvm.org/D88454
This is an alternate fix (see D87835) for a bug where a NaN constant
gets wrongly transformed into Infinity via truncation.
In this patch, we uniformly convert any SNaN to QNaN while raising
'invalid op'.
But we don't have a way to directly specify a 32-bit SNaN value in LLVM IR,
so those are always encoded/decoded by calling convert from/to 64-bit hex.
See D88664 for a clang fix needed to allow this change.
Differential Revision: https://reviews.llvm.org/D88238
Add Thread Local Storage support for the 34 bit relocation R_PPC64_GOT_TLSGD_PCREL34 used in General Dynamic.
The compiler will produce code that looks like:
```
pla r3, x@got@tlsgd@pcrel R_PPC64_GOT_TLSGD_PCREL34
bl __tls_get_addr@notoc(x@tlsgd) R_PPC64_TLSGD
R_PPC64_REL24_NOTOC
```
LLD should be able to correctly compute the relocation for R_PPC64_GOT_TLSGD_PCREL34 as well as do the following two relaxations where possible:
General Dynamic to Local Exec:
```
paddi r3, r13, x@tprel
nop
```
and General Dynamic to Initial Exec:
```
pld r3, x@got@tprel@pcrel
add r3, r3, r13
```
Note:
This patch adds support for the PC Relative (no TOC) version of General Dynamic on top of the existing support for the TOC version of General Dynamic.
The ABI does not provide any way to tell by looking only at the relocation `R_PPC64_TLSGD` when it is being used in a TOC instruction sequence or and when it is being used in a no TOC sequence. The TOC sequence should always be 4 byte aligned. This patch adds one to the offset of the relocation when it is being used in a no TOC sequence. In this way LLD can tell by looking at the alignment of the offset of `R_PPC64_TLSGD` whether or not it is being used as part of a TOC or no TOC sequence.
Reviewed By: NeHuang, sfertile, MaskRay
Differential Revision: https://reviews.llvm.org/D87318
If FP exceptions are ignored, we should not error out of compilation
just because APFloat indicated an exception.
This is required as a preliminary step for D88238
which changes APFloat behavior for signaling NaN convert() to set
the opInvalidOp exception status.
Currently, there is no way to trigger this error because convert()
never sets opInvalidOp. FP binops that set opInvalidOp also create
a NaN, so the path to checkFloatingPointResult() is blocked by a
different diagnostic:
// [expr.pre]p4:
// If during the evaluation of an expression, the result is not
// mathematically defined [...], the behavior is undefined.
// FIXME: C++ rules require us to not conform to IEEE 754 here.
if (LHS.isNaN()) {
Info.CCEDiag(E, diag::note_constexpr_float_arithmetic) << LHS.isNaN();
return Info.noteUndefinedBehavior();
}
return checkFloatingPointResult(Info, E, St);
Differential Revision: https://reviews.llvm.org/D88664
Summary:
Adds support for "following" memory through MSSA PHI arguments. This will help catch more noop stores that exist between blocks.
Originally part of D79391.
Reviewers: fhahn, jfb, asbirlea
Differential Revision: https://reviews.llvm.org/D82588
A new hidden option -print-changed is added along with code to support
printing the IR as it passes through the opt pipeline in the new pass
manager. Only those passes that change the IR are reported, with others
only having the banner reported, indicating that they did not change the
IR, were filtered out or ignored. Filtering of output via the
-filter-print-funcs is supported and a new supporting hidden option
-filter-passes is added. The latter takes a comma separated list of pass
names and filters the output to only show those passes in the list that
change the IR. The output can also be modified via the -print-module-scope
function.
The code introduces an abstract template base class that generalizes the
comparison of IRs that takes an IR representation as template parameter.
Derived classes provide overrides that provide an event based API
for generalized reporting of IRs as they are changed in the opt pipeline
through the new pass manager.
The first of several instantiations is provided that prints the IR
in a form similar to that produced by -print-after-all with the above
mentioned filtering capabilities. This version, and the others to
follow will be introduced at the upcoming developer's conference.
Reviewed By: aeubanks (Arthur Eubanks), yrouban (Yevgeny Rouban), ychen (Yuanfang Chen), MaskRay (Fangrui Song)
Differential Revision: https://reviews.llvm.org/D86360
A WRITE to an unformatted sequential variable-length unit after
a BACKSPACE needs to forget its previous knowledge of the length
of the record that's about to be overwritten, and a BACKSPACE
after an ENDFILE or at the start of the file needs to be a no-op.
Differential revision: https://reviews.llvm.org/D88675
This is a temporary workaround until the new/delete situation is made
better (i.e. we don't include new/delete in both libc++ and libc++abi
by default).
Don't give false positives from INQUIRE about possible
access mode changes on connected units. DIRECT and SEQUENTIAL
cannot be intermixed, apart from allowing DIRECT on a SEQUENTIAL
file with fixed-size records and positioning. Nor can
FORMATTED and UNFORMATTED be interchanged. On unconnected
files, the best that we can do is "UNKNOWN".
Differential revision: https://reviews.llvm.org/D88673
Some projects do not use the TEMP_FAILURE_RETRY macro but define their
own one, as not to depend on glibc / Bionic details. By allowing the
user to override the list of macros, these projects can also benefit
from this check.
Differential Revision: https://reviews.llvm.org/D83144
Add checking to I/O statement APIs to catch cases where the formatted
I/O data item transfer routines like OutputInteger64 are being
incorrectly used for unformatted I/O, which should use the
unformatted block or descriptor-based data item interfaces.
Differential revision: https://reviews.llvm.org/D88672
The user is expected to make the isStackSlot check before calling isPhysicalRegister
or isVirtualRegister. The APIs assert otherwise. We can improve the usability
of these APIs by carrying out the check in the 2 APIs: they become a
complete "source of truth" and remove an extra responsibility from the
user.
Differential Revision: https://reviews.llvm.org/D88598
https://reviews.llvm.org/D88310 fixed the AIX issue in LLVMExternalProjectUtils,
so we shouldn't need the workaround in the runtimes build anymore. I'm
reverting it because it prevents the target-specific tool selection in
LLVMExternalProjectUtils from taking effect, which we rely on for our
runtimes builds.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D88627
This is mostly for the benefit of the LBR latency mode.
Right now, it performs no checking. If this is run on non-supported hardware, it will produce all zeroes for latency.
Differential Revision: https://reviews.llvm.org/D85254
New change: Updated lit.local.cfg to use pass the right argument to llvm-exegesis to actually request the LBR mode.
Differential Revision: https://reviews.llvm.org/D88670
This allows us MSAN to instrument this function. Previous version is not
instrumentable due to it shear volume.
Differential Revision: https://reviews.llvm.org/D88536
This matches the corresponding existing case in
AArch64LoadStoreOpt::findMatchingUpdateInsnForward.
Both cases could also be modified to check
MBBI->getFlag(FrameSetup/FrameDestroy) instead of forbidding any
optimization involving SP, but the effect is probably pretty much
the same.
Differential Revision: https://reviews.llvm.org/D88541
The function already has a cleanup scope that calls the same whenever
the function is exited. When reading the code, seeing that this return
codepath has an explicit call while other return paths lack it is
confusing.
In the hypothetical case of a function having a prologue that
set the HasWinCFI flag in the MF, but the epilogue containing no
WinCFI instructions, the HasWinCFI flag in the MF would end up reset back
to false.
Differential Revision: https://reviews.llvm.org/D88636
Make sure we're using getScalarSizeInBits instead of cast<IntegerType> to get Type bit widths.
This is preliminary cleanup before we can start adding vector support to the bswap/bitreverse (element level) matching.
- `-cl-fp32-correctly-rounded-divide-sqrt` is already handled in a
per-instruction manner by annotating the accuracy required. There's no
need to add that fn-attr. So far, there's no in-tree backend handling
that attr and that OpenCL specific option.
- In case that out-of-tree backends are broken, this change could be
reverted if those backends could not be fixed.
Differential Revision: https://reviews.llvm.org/D88424
After this change all nodes that have a delimited-list are using the
`List` API.
Implementation details:
Let's look at a declaration with multiple declarators:
`int a, b;`
To generate a declarator list node we need to have the range of
declarators: `a, b`:
However, the `ClangAST` actually stores them as separate declarations:
`int a ;`
`int b;`
We solve that by appropriately marking the declarators on each separate
declaration in the `ClangAST` and then for the final declarator `int
b`, shrinking its range to fit to the already marked declarators.
Differential Revision: https://reviews.llvm.org/D88403
This is a tool to simply parse a file as clangd would, and run some
common features (code actions, go-to-definition, hover) in an attempt to
trigger or reproduce crashes, error diagnostics, etc.
This is easier and more predictable than loading the file in clangd, because:
- there's no editor/plugin variation to worry about
- there's no accidental variation of user behavior or other extraneous requests
- we trigger features at every token, rather than guessing
- everything is synchronoous, logs are easier to reason about
- it's easier to (get users to) capture logs when running on the command-line
This is a fairly lightweight variant of this idea.
We could do a lot more with it, and maybe we should.
But I can't in the near future, and experience will tell us if we made
the right tradeoffs and if it's worth investing further.
Differential Revision: https://reviews.llvm.org/D88338
Amara Emerson