Y is the start of several 2 letter constraints, but we also had
partial support to recognize it by itself. But it doesn't look
like it can get through clang as a single letter so the backend
support for this was effectively dead.

A few documentation clarifications and moving one part of the
docs around to be closer to the first mention of display so that
it's easier to spot based on some user feedback.

Differential Revision: https://reviews.llvm.org/D79443

When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the right place to have a global store of
local paths.

Differential Revision: https://reviews.llvm.org/D79364

Bug reported by @uabelho against reviews.llvm.org/D72841

Reviewers: rjmccall

Differential Revision: https://reviews.llvm.org/D79510

When debugging from a SymbolMap the creation of CompileUnits for the
individual object files is so lazy that RegisterXcodeSDK() is not
invoked at all before the Swift TypeSystem wants to read it. This
patch fixes this by introducing an explicit
SymbolFile::ParseXcodeSDK() call that can be invoked deterministically
before the result is required.

<rdar://problem/62532151+62326862>

https://reviews.llvm.org/D79273

This reverts commit 52cc8bac.

As the discussion in https://reviews.llvm.org/D78200 continues, I will
revert this until we figure out what to do.

passed to __builtin_os_log_format to extend its lifetime to the end of
its enclosing block

Extend only lifetimes of pointers returned by function calls or message
sends instead. In the long term, we should lifetime-extend pointers in
more complex expressions and non-ARC objects (e.g., C++ temporaries)
too.

rdar://problem/61846261

This was originally the way this worked before before
https://reviews.llvm.org/D60882.

In retrospect it seems inconsistent that `--allow-undefined` doesn't
work for all symbols.  See:
https://groups.google.com/g/emscripten-discuss/c/HSRgQiIq1gI/m/Kt9oFWHiAwAJ

I'm also planning a followup change which implement the full
`--unresolved-symbols=..` flags supported by ELF linkers (both ld and
ld.lld) since it seems more standard.

Differential Revision: https://reviews.llvm.org/D79247

Summary: I updated the code that produces the message and the associated test.

Reviewers: sscalpone, DavidTruby

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79514

This reverts commit 06591b6d.

Before this patch, the debug record S_GTHREAD32 which represents global thread_local symbols, was emitted by LLD into the respective module stream. This makes Visual Studio unable to display thread_local symbols in the debugger.

After this patch, S_GTHREAD32 is moved into the globals stream. This matches MSVC behavior.

Differential Revision: https://reviews.llvm.org/D79005

Add a way to get mutable equivalence sets to Scope so that they can
have sizes and offsets assigned to them.

Change CommonBlockDetails to have mutable symbols so that they can have
sizes and offets assigned to them. This also allows the removal of some
`const_cast`s.

Add MutableSymbolRef and MutableSymbolVector as mutable analogs to
SymbolRef and SymbolVector. Replace uses of equivalent types with those
names.

Differential Revision: https://reviews.llvm.org/D79346

When using vec_load/store_len_r with an immediate length operand
of 16 or larger, LLVM will currently emit an VLRL/VSTRL instruction
with that immediate.  This creates a valid encoding (which should be
supported by the assembler), but always traps at runtime.  This patch
fixes this by not creating VLRL/VSTRL in those cases.

This would result in loading the length into a register and
calling VLRLR/VSTRLR instead.  However, these operations with
a length of 15 or larger are in fact simply equivalent to a
full vector load or store.  And in fact the same holds true for
vec_load/store_len as well.

Therefore, add a DAGCombine rule to replace those operations with
plain vector loads or stores if the length is known at compile
time and equal or larger to 15.

Summary: systemd recently added a clang-format file. One issue I
encountered in using clang-format on systemd is that systemd does
not add a space before the parens of their foreach macros but
clang-format always adds a space. This does not seem to be
configurable in clang-format. This revision adds the
ControlStatementsExceptForEachMacros option to SpaceBeforeParens
which puts a space before all control statement parens except
ForEach macros. This drastically reduces the amount of changes
when running clang-format on systemd's source code.

Reviewers: MyDeveloperDay, krasimir, mitchell-stellar

Reviewed By: MyDeveloperDay

Subscribers: cfe-commits

Tags: #clang-format, #clang

Differential Revision: https://reviews.llvm.org/D78869

Calling getShiftAmountTy with LegalTypes set may return a type that's too narrow to hold the shift amount for integer type it's applied to.

Fixes the regression introduced by D79096

Differential Revision: https://reviews.llvm.org/D79405

Rename op trait PolyhedralScope -> AffineScope for consistency.

Differential Revision: https://reviews.llvm.org/D79503

Objects in common blocks have offsets relative to the start of the
common block, independent of the enclosing scope, so they are processed
first. Add alignment to CommonBlockDetails to record the required
alignment of the common block.

For equivalence sets, each object depends on the one that is forced to
occur first in memory. The rest are recorded in the dependents_ map and
have offsets assigned after the other symbols are done.

Differential Revision: https://reviews.llvm.org/D79347

When the folding is performed in place, the `::fold` function does not populate
its `results` argument to indicate that. (In the folding hook for single-result
operations, the result of the original operation is expected to be returned,
but it is then ignored by the wrapper.) `OperationFolder::create` would
erronously rely on the _operation_ having zero results instead of on the
_folding_ producing zero new results to populate the list of results with those
of the original operation. This would lead to a crash for single-result ops
with in-place folds where the first result is accessed uncondtionally because
the list of results was not properly populated. Use the list of values produced
by the folding instead.

Differential Revision: https://reviews.llvm.org/D79497

Depends on D79360 / rG2f1fe186 for the transform.

Summary: - Need to include checking on the new 16-bit subregs.

Reviewers: rampitec

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, kerbowa, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79498

This reverts commit 95aa28cc.

Summary:
If the only use of a value is a start or end lifetime intrinsic then mark the intrinsic as trivially dead. This should allow for that value to then be removed as well.

Currently, this only works for allocas, globals, and arguments.

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79355

Summary:
Math results are compared with MPFR results by checking if they are
within a tolerance level of the MPFR result. The tolerance level is set
using additional bits of precision of the fractional part of a floating
point value. Hence, the actual value of the tolerance depends on not
only the additional bits, but also on the exponent part of the floating
point number.

Previously, the exponent part was not considered in evaluating the
tolerance value. While it was OK for small values less than 1 (hence
sinf, cosf, sincosf tests were OK), it breaks for large values which
functions like exp and friends produce. This change uses the exponent
value also to evaluate the tolerance value. LLVM libc produced results
can now be compared with MPFR produced results for large values also.

Reviewers: abrachet

Differential Revision: https://reviews.llvm.org/D79278

Summary:
- Add license header.
- Remove TODO about extracting ShapeBase.td

Differential Revision: https://reviews.llvm.org/D79506

This helped fix some i686 vXi64 broadcast folds that were becoming v2Xi32 broadcasts because we didn't match the broadcast until after SimplifyDemandedBits worked out we only used the bottom 32-bits in PMUL(U)DQ and type legalization had split the original i64 load.

A couple of regressions occurred which required some fixups - adding concat_vectors(broadcast_load,broadcast_load) splat support and recognising (unnecessary) unary shuffles of already broadcasted vectors.

This came about as part of the work investigating vector load combining from shuffles for PR42550.

We never need to call this from anything but ISD::SHUFFLE_VECTOR or target shuffles so shouldn't need to address SDNode directly.

This is unusual for the general case because we are replacing
1 instruction with 2.

Splitting from a potential conflicting transform in D79171

Reviewed By: nickdesaulniers

Differential Revision: https://reviews.llvm.org/D79495

Summary:
Any function in this module that make use of DemandedElts laregely does
not work with scalable vectors. DemandedElts is used to define which
elements of the vector to look at. At best, for scalable vectors, we can
express the first N elements of the vector. However, in practice, most
code that uses these functions expect to be able to talk about the
entire vector. In principle, this module should be able to be extended
to work with scalable vectors. However, before we can do that, we should
ensure that it does not cause code with scalable vectors to miscompile.
All functions that use a DemandedElts will bail out if the vector is
scalable. Usages of getNumElements() are updated to go through
FixedVectorType pointers.

Reviewers: rengolin, efriedma, sdesmalen, c-rhodes, spatel

Reviewed By: efriedma

Subscribers: david-arm, tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79053

Summary:
This will enable extraction of correct line locations in preamble patch
for includes.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78740

When running on remote hosts, we need the whole `echo 123 | %t.exe` command
to run on the remote host. Thus, we need to escape the pipe to make sure
the command is treated as `{ echo 123 | %t.exe } > %t.out` instead of
`{ echo 123 } | %t.exe > %t.out`m where only `echo 123` is run on the
remote host.

Running `export` when there is no environment variable to export will
cause the environment on the remote host to be printed. We don't want
that, so don't run any `export` command on the host when there's no env.

This reverts commit e38018b8.

We do not want to break asm syntax. These suffixes are
quite useful for debugging, so add an option to print
them. Right now it is NFC.

Differential Revision: https://reviews.llvm.org/D79435

When called from the post-RA scheduler, hazards have already been
handled by getHazardType returning NoopHazard, so PreEmitNoops always
returns zero. Remove it. NFC.

Historical note: PreEmitNoops was added to the hazard recognizer
interface as an optional feature to support dispatch group formation on
the POWER target:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20131202/197470.html
So it seems right that we shouldn't need to implement it.

We do still implement the other overload PreEmitNoops(MachineInstr *)
because that is used by the PostRAHazardRecognizer pass.

Differential Revision: https://reviews.llvm.org/D79476

This patch adds more constant materialization tests, focusing on cases where
we could improve our materialization instruction sequences (particularly for
RV64). Various of these cases will be improved upon in follow-up patches.

Differential Revision: https://reviews.llvm.org/D79453

Reviewers: rjmccall, erichkeane, sepavloff

Differential Revision: https://reviews.llvm.org/D78827

Much like the similar combine added recently for VMOVrh load, this
adds a fold for VMOVhr load turning it into a vldr.f16 as opposed to a
vldrh and vmov.f16.

Differential Revision: https://reviews.llvm.org/D78714