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

The generic vectorization pattern handles only those cases, where
low and high padding is zero. This is already handled by a
canonicalization pattern.

Also add a new canonicalization test case to ensure that tensor cast ops
are properly inserted.

A more general vectorization pattern will be added in a subsequent commit.

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

This allows it to be default constructible, which makes sense given it
ignores the operand.

Vectorize linalg.pad_tensor without generating a linalg.init_tensor when consumed by a transfer_write.

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

Vectorize linalg.pad_tensor without generating a linalg.init_tensor when consumed by a subtensor_insert.

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

Vectorize linalg.pad_tensor without generating a linalg.init_tensor when consumed by a transfer_read.

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

* Add a helper function that returns the constant padding value (if applicable).
* Remove existing getConstantYieldValueFromBlock function, which does almost the same.
* Adapted from D103243.

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

This patch adds missing keyword highlights for freeze and poison

Reviewed By: MaskRay, porglezomp

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

I wanted to see if we would get any perf wins out of this, but
it doesn't seem to be the case. But it still seems worth committing.

Reviewed By: MaskRay

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

We don't need to define any special behavior for this section,
so creating a subclass for it is redundant.

Reviewed By: #lld-macho, thakis

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

`outSecFileOff` and the associated `getFileOffset()` accessors were
unnecessary.

For all the cases we care about, `outSecFileOff` is the same as
`outSecOff`. The only time they deviate is if there are zerofill
sections within a given segment. But since zerofill sections are always
at the end of a segment, the only sections where the two values deviate
are zerofill sections themselves. And we never actually query the
outSecFileOff of zerofill sections.

As for `getFileOffset()`, the only place it was being used was to
calculate the offset of the entry symbol. However, we can compute that
value by just taking the difference between the address of the entry
symbol and the address of the Mach-O header. In fact, this appears to be
what ld64 itself does. This difference is the same as the file offset as
long as there are no intervening zerofill sections, but since `__text`
is the first section in `__TEXT`, this never happens, so our previous
use of `getFileOffset()` was not wrong -- just inefficient.

Reviewed By: #lld-macho, thakis

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

Handle "short" in a case-insensitive fashion in MASM.

Required to correctly parse z_Windows_NT-586_asm.asm from the OpenMP runtime.

Reviewed By: thakis

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

These directives are matched in lowercase, so make sure to use lowercase for their P suffix.

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

Did not correctly handle "jecxz short <address>".

Discovered while working on LLVM-ML; shows up in z_Windows_NT-586_asm.asm from the OpenMP runtime

Reviewed By: MaskRay

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

This was regressed in adf1561d.  Since gcc does not support
`__has_feature`, this adjusts the build to use the
`__SANITIZE_ADDRESS__` macro which GCC defines to identify if ASAN is
enabled (similar to `__has_feature`).  This allows building libunwind
with gcc again.

Patch by Daniel Levin!

Reviewed By: compnerd

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

Some of these can be DSE'd, some of which cannot. Useful in D100464.

Add `tensor.insert` op to make `tensor.extract`/`tensor.insert` work in pairs
for `scalar` domain. Like `subtensor`/`subtensor_insert` work in pairs in
`tensor` domain, and `vector.transfer_read`/`vector.transfer_write` work in
pairs in `vector` domain.

Reviewed By: silvas

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

This implements https://sourceware.org/bugzilla/show_bug.cgi?id=26404

An `OVERWRITE_SECTIONS` command is a `SECTIONS` variant which contains several
output section descriptions. The output sections do not have specify an order.
Similar to `INSERT [BEFORE|AFTER]`, `LinkerScript::hasSectionsCommand` is not
set, so the built-in rules (see `docs/ELF/linker_script.rst`) still apply.
`OVERWRITE_SECTIONS` can be more convenient than `INSERT` because it does not
need an anchor section.

The initial syntax is intentionally narrow to facilitate backward compatible
extensions in the future. Symbol assignments cannot be used.

This feature is versatile. To list a few usage:

* Use `section : { KEEP(...) }` to retain input sections under GC
* Define encapsulation symbols (start/end) for an output section
* Use `section : ALIGN(...) : { ... }` to overalign an output section (similar to ld64 `-sectalign`)

When an output section is specified by both `OVERWRITE_SECTIONS` and
`INSERT`, `INSERT` is processed after overwrite sections. To make this work,
this patch changes `InsertCommand` to use name based matching instead of pointer
based matching. (This may cause a difference when `INSERT` moves one output
section more than once. Such duplicate commands should not be used in practice
(seems that in GNU ld the output sections may just disappear).)

A linker script can be used without -T/--script. The traditional `SECTIONS`
commands are concatenated, so a wrong rule can be more noticeable from the
section order. This feature if misused can be less noticeable, just like
`INSERT`.

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

cstddef is needed for size_t definition.
(Multiple headers can provide size_t but none of them exists.)

Reviewed By: MaskRay

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

This adds a new formatter to arrange array of struct initializers into
neat columns.

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

Lower truncations and expansions between fp128 and half values into libcalls.
Expand truncating stores into two separate truncation and a store operations.

Reviewed By: jrtc27

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

Ultimately the DirectoryWatcher is not ready until the notifier thread
is also active.  Failure to wait for the notifier thread may result in
loss of events.  While this is not catastrophic in practice, the tests
are sensitive to this as depending on the thread scheduler, the thread
may fail to being execution before the operations are completed by the
fixture.  Running this in a tight loop shows no regressions locally as
previously, but this failure mode was been sighted once on a builder.

This is a "we should do X in the future" fixme, not an "X might go wrong"
fixme.

The (prior to prologue insertion) predictable exit shouldn't get
folded here. Make sure it isn't...

We don't use <vector> but we do use std::pair (<utility>)

We don't use <string> but we do use std::unique_ptr (<memory>) and llvm::Optional<>

Don't create std::string from constant c-strings or pass std::string by value - we can use StringRef instead.

We don't use <algorithm>, <set> or <vector>, but we do use std::pair (<utility>).

This adds t2WhileLoopStartTP, similar to the t2DoLoopStartTP added in
D90591. It keeps a reference to both the tripcount register and the
element count register, so that the ARMLowOverheadLoops pass in the
backend can pick the correct one without having to search for it from
the operand of a VCTP.

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

This patch addresses a performance issue I noticed when using clang-12 to compile projects of mine. Even though the files weren't too large (around 1k cpp), the compiler was taking more than a minute to compile the source file, much longer than either GCC or MSVC.

Using a profiler it turned out the issue was the isAnyDestructorNoReturn function in CXXRecordDecl. In particular it being recursive, recalculating the property for every invocation, for every field and base class. This showed up in tracebacks in the profiler.

This patch instead adds IsAnyDestructorNoReturn as a Field to the data inside of CXXRecord and updates when a new base class, destructor, or record field member is added.

After this patch the problematic file of mine went from a compile time of 81s, down to 12s.

The patch itself should not change any functionality, just improve performance.

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

https://alive2.llvm.org/ce/z/tX4pUT