Repeatedly calling getName adds some overhead, which can be easily
avoided by querying the name just once per function. The improvements
are rather small (~0.5% back-end time in a compile-time optimized
setting), but also very easy to achieve.

Note that getting the name should be entirely avoidable in the common
case, but would require more substantial changes.

Reviewed By: MaskRay

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

Following a suggestion from Erich in https://reviews.llvm.org/D148101,
this patch bumps AS_GNU to 1 so that syntax 0 is invalid.  It also
asserts that the syntax is in range.

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

AttributeCommonInfo::isAlignasAttribute() was used in one place:
isCXX11Attribute().  The intention was for isAlignasAttribute()
to return true for the C++ alignas keyword.  However, as a FIXME
noted, the function also returned true for the C _Alignas keyword.
This meant that isCXX11Attribute() returned true for _Alignas as
well as for alignas.

AttributeCommonInfos are now always constructed with an
AttributeCommonInfo::Form.  We can use that Form to convey whether
a keyword is alignas or not.

The patch uses 1 bit of an 8-bit hole in the current layout
of AttributeCommonInfo.  This might not be the best long-term design,
but it should be easy to adapt the layout if necessary (that is,
if other uses are found for the spare bits).

I don't know of a way of testing this (other than grep -c FIXME)

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

This patch adds static functions for constructing most
AttributeCommonInfo::Forms.  Direct construction is only retained where
all fields (currently the syntax and spelling) are specified explicitly.

This is a wash on its own.  The purpose is to allow extra fields
to be added to Form without disrupting all callers.  In particular,
it allows extra information to be stored about keywords without
affecting non-keyword uses.

No functional change intended.

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

This patch adds an extra AttributeCommonInfo::Form constructor
for keywords, represented by their TokenKind.  This isn't a
win on its own, but it helps with later patches.

No functional change intended.

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

When constructing an attribute, the syntactic form was specified
using two arguments: an attribute-independent syntax type and an
attribute-specific spelling index.  This patch replaces them with
a single argument.

In most cases, that's done using a new Form class that combines the
syntax and spelling into a single object.  This has the minor benefit
of removing a couple of constructors.  But the main purpose is to allow
additional information to be stored as well, beyond just the syntax and
spelling enums.

In the case of the attribute-specific Create and CreateImplicit
functions, the patch instead uses the attribute-specific spelling
enum.  This helps to ensure that the syntax and spelling are
consistent with each other and with the Attr.td definition.

If a Create or CreateImplicit caller specified a syntax and
a spelling, the patch drops the syntax argument and keeps the
spelling.  If the caller instead specified only a syntax
(so that the spelling was SpellingNotCalculated), the patch
simply drops the syntax argument.

There were two cases of the latter: TargetVersion and Weak.
TargetVersionAttrs were created with GNU syntax, which matches
their definition in Attr.td, but which is also the default.
WeakAttrs were created with Pragma syntax, which does not match
their definition in Attr.td.  Dropping the argument switches
them to AS_GNU too (to match [GCC<"weak">]).

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

The purpose of this patch and follow-on patches is to ensure that
AttributeCommonInfos always have a syntax that is appropriate for
their kind (i.e. that it matches one of the entries in Attr.td).

The attribute-specific Create and CreateImplicit methods had four
overloads, based on their tail arguments:

(1) no extra arguments
(2) an AttributeCommonInfo
(3) a SourceRange
(4) a SourceRange, a syntax, and (where necessary) a spelling

When (4) had a spelling argument, it defaulted to
SpellingNotCalculated.

One disadvantage of this was that (1) and (3) zero-initialized
the syntax field of the AttributeCommonInfo, which corresponds
to AS_GNU.  But AS_GNU isn't always listed as a possibility
in Attr.td.

This patch therefore removes (1) and (3) and instead provides
the same functionality using default arguments on (4) (a bit
like the existing default argument for the spelling).
The default syntax is taken from the attribute's first valid
spelling.

Doing that raises the question: what should happen for attributes
like AlignNatural and CUDAInvalidTarget that are only ever created
implicitly, and so have no source-code manifestation at all?
The patch adds a new AS_Implicit "syntax" for that case.
The patch also removes the syntax argument for these attributes,
since the syntax must always be AS_Implicit.

For similar reasons, the patch removes the syntax argument if
there is exactly one valid spelling.

Doing this means that AttributeCommonInfo no longer needs the
single-argument constructors.  It is always given a syntax instead.

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

[compiler-rt] [test] [builtins] Pass the right parameters for linking with -nodefaultlibs on mingw targets

The clang-cl/MSVC case is handled above, thus consider win32 && !is_msvc
to be mingw.

This matches the list of libraries passed by e.g. the libcxx build, when
using -nodefaultlibs.

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

When we initialize the UnwindCursor (unw_cursor_t) based on
an existing Registers object (unw_context_t), we only initialize
a subset of the class.

Fill the struct properly for the current thread with RtlCaptureContext,
followed by overwriting of the subset of registers that we do have
available in the Registers class.

One might think that it's enough to initialize specifically the
registers that we signal availability for with ContextFlags,
however in practice, that's not enough.

This fixes crashes when restoring the context via RtlRestoreContext
(via UnwindCursor::jumpto), via __unw_resume.

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

This fixes libunwind_01.pass.cpp for x86_64 Windows.

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

This parameter isn't essential for the execution of this test, so just
skip it when running tests in mingw mode.

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

Mingw toolchains always end up referencing the malloc symbol due to
the CRT startup files.

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

This test uses lots of lld-link specific linker options that don't
work as such in mingw command lines.

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

In mingw mode on x86, long doubles are 80 bit - while MSVC mode uses
long doubles that are equal to regular doubles (on all architectures).

In the case of this formatting function, we're calling a MS CRT
provided printf function which interprets long doubles as 64 bit.

Since the long doubles are equal to regular doubles on all MSVC
platforms, just use regular double formatting. For MSVC environments
there's no difference, but for mingw environments, this avoids the
ambiguity.

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

This passes the same option that was added for MSVC builds in
fb5a24b4 in the corresponding mingw form too.

This fixes the BVGraph tests in the sanitizer unit tests.

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

When this header now is a fully regular header within the src tree,
give it a more regular name.

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

It seems that existing logic is too strict about latch block exit count.
It is required to be computable, however it is not used in any computations,
and effectively the only thing it is used for is to get the type of computed
exit count.

Sometimes the exit count for latch block is not known, but the loop is still
finite because of other exits, and safe bounds are still computable. In this case,
we miss an opportunity to apply IRCE.
We could instead use a more relaxed version - max symbolic exit count, which,
if exists, is enough to say that the loop is finite, and its type should be good enough.

There is a subtlety with type: we do not support latch count type wider than range
check type. Because of that, we want to have the narrowest type available. So if it
can be computed from latch block immediately, take it. Otherwise, take whatever whole
loop provides and hope that it's type isn't too wide.

Differential Revision: https://reviews.llvm.org/D147910
Reviewed By: danilaml

This reverts commit 27c4777f.

It created problems for testing on Gentoo, see:
https://reviews.llvm.org/rG27c4777f41d2ab204c1cf84ff1cccd5ba41354da#1190273
Reverted until https://reviews.llvm.org/D147652 has been landed.

This was out of date and the link to the lldb tag will always be up to date.

The previous patch, D135564, was too conservative to avoid store interleave
for streaming-compatible functions/mode.

In this patch, we allow using the interleave store but using scalable vector.

Reviewed By: david-arm, sdesmalen

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

Support LLVM::StackSaveOp and LLVM::StackRestoreOp in the LLVM dialect
inliner in MLIR.

Inserts new LLVM::StackSaveOp and LLVM::StackRestoreOp intrinsics when
dynamic allocas are detected in the inlined blocks. This may result in
multiple saves/restores in the same block if some are already present in
the caller, which is legal IR, but is cleaned up in LLVM. There is not
yet a canonicalization pattern for this on LLVM dialect in MLIR.

Reviewed By: Dinistro

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

long is 32-bits on windows, so the test was failing with:

  error: cast from pointer to smaller type 'unsigned long' loses
  information

see e.g. https://lab.llvm.org/buildbot/#/builders/123/builds/18361

This is a follow-up to D144304

Reviewed By: craig.topper

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

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

No need to include CallGraphSCCPass.h from the IPO/Inliner.

Also removed the include of LegacyPassManager.h in a couple of files
that do not really depend on that header file.

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

Remove dead code related to "FPasses". This was a leftover from
commit 7a5332b9.

Do not mention -enable-new-pm in error messages. The option does
not exist any longer.

Remove the addPass helper. Only one use remained, so we can just
"inline" it manually to keep the code related to legacy PM a bit
less spread out.

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

This commit is removing the last pieces of AnalysisWrapper.cpp
(including the ExternalFunctionsPassedConstants pass, aka
print-externalfnconstants).

The pass only existed for the legacy PM, and it was not regression
tested. And since the pass did not force the use of the legacy pass
manager there was no simply way to run the pass nowadays, at least
not by using opt.

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

This removed the option print-breakpoints-for-testing in opt, as well
as the related BreakpointPrinter pass.

The functionality only existed for the legacy PM, but was not verified
to be working by any test cases. And the named "llvm.dbg.sp" metadata
that the pass was looking for is not something that I really can find
any information about (unless perhaps if I dive really deep into the
commit history), so not sure exactly if this functionality has been
relevant for several years.

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

This broke lit tests on Mac, see comment on the code review.

> Users have discovered [*] that when CONFIG_ARCH_MMAP_RND_BITS == 32,
> it will frequently conflict with ASan's allocator on x86-64 Linux, because the
> PIE program segment base address of 0x555555555554 plus an ASLR shift of up to
> ((2**32) * 4K == 0x100000000000) will sometimes exceed ASan's hardcoded
> base address of 0x600000000000. We fix this by simply moving the allocator base
> to 0x500000000000, which is below the PIE program segment base address. This is
> cleaner than trying to move it to another location that is sandwiched between
> the PIE program and library segments, because if either of those grow too large,
> it will collide with the allocator region.
>
> Note that we will never need to change this base address again (unless we want to increase
> the size of the allocator), because ASLR cannot be set above 32-bits for x86-64 Linux (th...

Fix crash in ASTImporter related to import of unnamed structures and typedefs
to these maybe with pointer.
There was a series of problems exposed by https://reviews.llvm.org/D133468
(commit 69a64174) in the ASTImporter breaking
cross-translation unit analysis. This change fixes one of the problems exposed
by that change for importing unnamed structures. The problem was
discovered when running clang static analysis on open source projects
using cross-translation unit analysis.

Simple test command. Produces crash without change, passes all tests
with change.

```
ninja ASTTests && ./tools/clang/unittests/AST/ASTTests
  --gtest_filter="*/*ImportAnonymousStruct/0"
```

Formatted crash stack:

```
ASTTests: <root>/clang/lib/AST/ASTContext.cpp:4787:
  clang::QualType clang::ASTContext::getTypedefType(const clang::TypedefNameDecl*,
  clang::QualType) const: Assertion `hasSameType(Decl->getUnderlyingType(), Underlying)' failed.
...
 #9 <addr> clang::ASTContext::getTypedefType(clang::TypedefNameDecl const*, clang::QualType) const
             <root>/clang/lib/AST/ASTContext.cpp:4789:26
             <root>/clang/lib/AST/ASTImporter.cpp:1374:71
             <root>/tools/clang/include/clang/AST/TypeNodes.inc:75:1
             <root>/clang/lib/AST/ASTImporter.cpp:8663:8
```

Reviewed By: donat.nagy

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

Close https://github.com/llvm/llvm-project/issues/62112

In the previous change, we'll stop parsing directly after we found
reserved module names. But this may be too aggressive. This patch
changes this. Note that the parsing will still be stopped if the module
name is `module` or `import`.

This gives us better control to lower masked operations independently of the create mask operations.
It is often useful to maintain high-level mask information instead of lowering it too early to
too fine-grained form.

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

It broke lit tests on Mac, see comments on the code review.

> Reviewed By: vitalybuka, dvyukov
>
> Differential Revision: https://reviews.llvm.org/D147337

This reverts commit ebb0f1d0 and
follow-up commit 3c83aeee.

Fix #61691

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

Apparently it was used to work around some issue that has been fixed.
Removing it helps with high scratch usage observed in some cases due to failed alloca promotion.

Reviewed By: rampitec

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

According to
https://llvm.org/docs/HowToUpdateDebugInfo.html#when-to-preserve-an-instruction-location,
when moving (and in our case cloning) within the same BB, the debug
location is preserved. But when moving / cloning to a different BB, we
preserve the debug location only if the destination BB contains the same
location. Currently we preserve the debug loc unconditionally in all
cases. This CL correctly handles the debug locs in DebugValueManager.

Reviewed By: dschuff

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