The previous impl densely scanned the entire region starting with an op
when dominators were created, creating a DominatorTree for every region.

This is extremely expensive up front -- particularly for clients like
Linalg/Transforms/Fusion.cpp that construct DominanceInfo for a single
query.  It is also extremely memory wasteful for IRs that use single
block regions commonly (e.g. affine.for) because it's making a
dominator tree for a region that has trivial dominance.  The
implementation also had numerous unnecessary minor efficiencies, e.g.
doing multiple walks of the region tree or tryGetBlocksInSameRegion
building a DenseMap that it didn't need.

This patch switches to an approach where [Post]DominanceInfo is free
to construct, and which lazily constructs DominatorTree's for any
multiblock regions that it needs.  This avoids the up-front cost
entirely, making its runtime proportional to the complexity of the
region tree instead of # ops in a region.  This also avoids the memory
and time cost of creating DominatorTree's for single block regions.

Finally this rewrites the implementation for simplicity and to avoids
the constant factor problems the old implementation had.

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

We were mistakenly treating `.debug_str_offsets` as a string mergable
section when it is not (it contains integers not strings).  This is an
indication that we really should find a way to store flags for custom
sections.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=48828
Fixes: https://bugs.chromium.org/p/chromium/issues/detail?id=1172217

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

Refs https://eel.is/c++draft/default.sentinel and https://eel.is/c++draft/iterator.synopsis

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

fixup: Missing operator in [globalisel][legalizer] Separate the deprecated LegalizerInfo from the current one

My local compiler was fine with it but the bots complain about ambiguous types.

If there is an error reading the dylib, we shouldn't try
to load its reexports.

Caught e.g. by https://lab.llvm.org/buildbot/#/builders/36/builds/8946

The compiler used on Apple bots doesn't know about -std=c++20 yet, so
we can't use that just yet.

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

Depthwise convolution should support kernel dilation and non-dilation should
not be a special case. Updated op definition to include a dilation attribute.

This also adds a tosa.depthwise_conv2d lowering to linalg to support the new
linalg behavior.

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

It's still in use in a few places so we can't delete it yet but there's not
many at this point.

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

This gives a nice message about the location of errors in a large
tablegen file, which is much more useful for users

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

This omits load commands for unreferenced dylibs if:
- the dylib was loaded implicitly,
- it is marked MH_DEAD_STRIPPABLE_DYLIB
- or -dead_strip_dylibs is passed

This matches ld64.

Currently, the "is dylib referenced" state is computed before dead code
stripping and is not updated after dead code stripping. This too matches ld64.
We should do better here.

With this, clang-format linked with lld (like with ld64) no longer has
libobjc.A.dylib in `otool -L` output. (It was implicitly loaded as a reexport
of CoreFoundation.framework, but it's not needed.)

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

WindowsSupport.h is a public header, however if it gets included, will cause a compile error indicating that llvm/Config/config.h cannot be found, because config.h is a private header. However there is no actual dependency on the private things in this header, so it can be changed to the public config header.

Reviewed By: amccarth

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

https://llvm.org/PR49543

- A lot of lit tests simply specify the arch minus the triple. On z/OS, this could result in a scenario of some-other-triple-unknown-ibm-zos. This points to an incorrect triple + arch combo.
- To prevent this, isOSzOS change is switched in favour of isOSBinFormatGOFF.
- This is because, the GOFF format is set only if the triple is systemz and if the operating system is GOFF. And currently, there are no other architectures/os's using the GOFF file format.
- An argument could be made that the problematic tests be fixed to explicitly specify the arch-vendor-triple string, but there's a large number of these tests, and adding this stricter scope ensures that we aren't instantiating the incorrect instance of the AsmParser for other platforms when run on z/OS.

Reviewed By: uweigand

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

This addresses pr50497. The argument of a typeid expression is
unevaluated, *except* when it's a polymorphic type. We handle this by
parsing as unevaluated and then transforming to evaluated if we
discover it should have been an evaluated context.

We do the same in TreeTransform<Derived>::TransformCXXTypeidExpr,
entering unevaluated context before transforming and rebuilding the
typeid. But that's incorrect and can lead us to converting to
evaluated context twice -- and hitting an assert.

During normal template instantiation we're always cloning the
expression, but during generic lambda processing we do not necessarily
AlwaysRebuild, and end up with TransformDeclRefExpr unconditionally
calling MarkDeclRefReferenced around line 10226. That triggers the
assert.

// Mark it referenced in the new context regardless.
// FIXME: this is a bit instantiation-specific.
SemaRef.MarkDeclRefReferenced(E);

This patch makes 2 changes.

a) TreeTransform<Derived>::TransformCXXTypeidExpr only enters
unevaluated context if the typeid's operand is not a polymorphic
glvalue. If it is, it keeps the same evaluation context.

b) Sema::BuildCXXTypeId is altered to only transform to evaluated, if
the current context is unevaluated.

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

This will unblock work on ranges::view. Based on D101396.

Refs http://eel.is/c++draft/view.interface.

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

loadDylib() keeps a name->DylibFile cache, but it only writes
to the cache once the DylibFile constructor has completed.
So dylib loads done recursively from the DylibFile constructor
wouldn't use the cache.

Now, we load additional dylibs after writing to the cache,
which means the cache now gets used for dylibs loaded because
they're referenced from other dylibs.

Related to PR49514 and PR50101, but no dramatic behavior change in itself.
(Technically we no longer crash when a tbd file reexports itself,
but that doesn't happen in practice. We now accept it silently instead
of crashing; ld64 has a diag for the reexport cycle.)

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

This is important for build determinism. This matches ld64.

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

This must have made to code by accident.

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

As the existing test unreachable.ll shows, we should be doing more
work to avoid entering unreachable blocks: we should not stop
vectorization just because a PHI incoming value from an unreachable
block cannot be vectorized. We know that particular value will never
be used so we can just replace it with poison.

When on KNL and L2 or Tile layer is detected, manually add
the corresponding layer which is equivalent.

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

We now make up a TypeLoc for the class receiver to simplify visiting,
notably for indexing, availability, and clangd.

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

Each var argument to an attach or detach clause must be a
Fortran variable or array with the pointer or allocatable attribute.
This patch enforce this restruction.

Reviewed By: kiranchandramohan

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

WrapperFunctionResult is a C++ wrapper for __orc_rt_CWrapperFunctionResult
that automatically manages the underlying struct.

The Simple Packed Serialization (SPS) utilities support a simple serialization
scheme for wrapper function argument and result buffers:

Primitive typess (bool, char, int8_t, and uint8_t, int16_t, uint16_t, int32_t,
uint32_t, int64_t, uint64_t) are serialized in little-endian form.

SPSTuples are serialized by serializing each of the tuple members in order
without padding.

SPSSequences are serialized by serializing a sequence length (as a uint64_t)
followed by each of the elements of the sequence in order without padding.

Serialization/deserialization always involves a pair of SPS type tag (a tag
representing the serialized format to use, e.g. uint32_t, or
SPSTuple<bool, SPSString>) and a concrete type to be serialized from or
deserialized to (uint32_t, std::pair<bool, std::string>). Serialization for new
types can be implemented by specializing the SPSSerializationTraits type.

This matches the C++ namespace name, and is consistent with other C linkage
functions (e.g. __orc_rt_jit_dispatch).

Also added missing Fortran definitions for interop support.

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

When applying the changes in 8edd3464,
it seems that this bit got merged incorrectly and no test coverage
caught the issue. This fixes the diagnostic and adds a test.

Also add a target hook which allows us to get around custom legalization on
AArch64.

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

Until I figure out what the issue is with this test on AppleClang (and
in particular which change caused it), I want to avoid all CI being broken.

When completing an Objective-C method declaration by name, we need to
preserve the leading text as a `qualifier` so we insert it properly
before the first typed text chunk.

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

This patch transforms the sequence

    lea (reg1, reg2), reg3
    sub reg3, reg4

to two sub instructions

    sub reg1, reg4
    sub reg2, reg4

Similar optimization can also be applied to LEA/ADD sequence.
The modifications to TwoAddressInstructionPass is to ensure the operands of ADD
instruction has expected order (the dest register of LEA should be src register of ADD).

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

Since fd7e309e this is no longer
pulled in indirectly through DenseMapInfo.h.

This is currently NFC on benchmarks and tests.

Review: Ulrich Weigand

When we're remapping an AddRec, the AddRec constructed by a partial
rewrite might not make sense.  This triggers an assertion complaining
it's not loop-invariant.

Instead of constructing the partially rewritten AddRec, just skip
straight to calling evaluateAtIteration.

Testcase was automatically reduced using llvm-reduce, so it's a little
messy, but hopefully makes sense.

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

As suggested in https://bugs.llvm.org/show_bug.cgi?id=50527, this
moves the DenseMapInfo for APInt and APSInt into the respective
headers, removing the need to include APInt.h and APSInt.h from
DenseMapInfo.h.

We could probably do the same from StringRef and ArrayRef as well.

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