For example, byval.

Skip the type attribute auto-upgrade if we already have the type.

I've actually seen this error of the ValueEnumerator missing a type
attribute's type in a non-opaque pointer context.

Reviewed By: nikic

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

Make these follow the update_test_checks.py format.

GlobalISel is relying on regular MachineMemOperands to track all of
the memory properties of accesses. Just the raw byte size is
insufficent to disambiguate all situations. For example, if we need to
split an unaligned extending load, we need to know the number of bits
in the original source value and can't infer it from the result
type. This is also a problem for extending vector loads.

This does decrease the maximum representable size from the full
uint64_t bytes to a maximum of 16-bits. No in tree testcases hit this,
other than places using UINT64_MAX for unknown sizes. This may be an
issue for G_MEMCPY and co., although they can just use unknown size
for large static sizes. This also has potential for backend abuse by
relying on the type when it really shouldn't be relevant after
selection.

This does not include the necessary MIR printer/parser changes to
represent this.

This reverts commit dc98adfb.

This should still be done, but this is currently causing some commit
ordering issues.

functions implicitly generated by the compiler

These fake functions would cause clang to crash if the changes proposed
in https://reviews.llvm.org/D98799 were made.

4506f614 fixed parsing of textual IR to
reject `ptr*`, but broke the auto-conversion of `i32**` to `ptr` with
`--force-opaque-pointers`.

Get that working again by refactoring LLParser::parseType to only send
`ptr`-spelled pointers into the type suffix logic when it's the return
of a function type. This also rejects `ptr addrspace(3) addrspace(2)`,
which 1e6303e6 invadvertently started
accepting. Just the default top-level error message for the
double-addrspace since I had trouble thinking of something nice;
probably it's fine as is (it doesn't look valid the way that `ptr*`
does).

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

1. Remove unnecessary templates.
2. Fix potentially unaligned reads inside constructSection.

Test plan: make check-all

Differential revision: https://reviews.llvm.org/D105089

An empty location is now printed as <empty>

When max flat workgroup size is not specified, it is set to the default
workgroup size. This prevents kernel launch with a workgroup size larger
than the default. The fix is to ignore a size of 0 and treat it as
unspecified.

Reviewed By: JonChesterfield

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

Previously, we required entrypoints.txt for every target architecture
supported by a target OS. With this change, we allow architecture
independent config for a target OS. That is, if an architecture specific
entrypoints.txt is missing, then a generic entrypoints.txt for that
target OS will be used.

Reviewed By: caitlyncano

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

-S replaced -s, so the test needs to be updated to use the new option

This allows application code checks if origin tracking is on before
printing out traces.

-dfsan-track-origins can be 0,1,2.
The current code only distinguishes 1 and 2 in compile time, but not at runtime.
Made runtime distinguish 1 and 2 too.

Reviewed By: browneee

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

* Previously, we were only generating .h.inc files. We foresee the need to also generate implementations and this is a step towards that.
* Discussed in https://llvm.discourse.group/t/generating-cpp-inc-files-for-dialects/3732/2
* Deviates from the discussion above by generating a default constructor in the .cpp.inc file (and adding a tablegen bit that disables this in case if this is user provided).
* Generating the destructor started as a way to flush out the missing includes (produces a link error), but it is a strict improvement on its own that is worth doing (i.e. by emitting key methods in the .cpp file, we root vtables in one translation unit, which is a non-controversial improvement).

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

Reverts commits:
"Fix failing tests after https://reviews.llvm.org/D104488."
"Fix buildbot failure after https://reviews.llvm.org/D104488."
"Create synthetic symbol names on demand to improve memory consumption and startup times."

This series of commits broke the windows lldb bot and then failed to fix all of the failing tests.

Depends On D105037

Avoid creating too many tasks when the number of workers is large.

Reviewed By: herhut

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

Depends On D104999

Automatic reference counting based on the liveness analysis can add a lot of reference counting overhead at runtime. If the IR is known to be constrained to few particular "shapes", it's much more efficient to provide a custom reference counting policy that will specify where it is required to update the async value reference count.

Reviewed By: mehdi_amini

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

This revision adds the minimal plumbing to create a simple ComprehensiveModuleBufferizePass that can behave conservatively in the presence of CallOps.

A topological sort of caller/callee is performed and, if the call-graph is cycle-free, analysis can proceed.

Differential revision: https://reviews.llvm.org/D104859

Added the option `-altivec-src-compat=[mixed,gcc,xl]`. The default at this time is `mixed`.

The default behavior for clang is for all vector compares to return a scalar unless the vectors being
compared are vector bool or vector pixel. In that case the compare returns a
vector. With the gcc case all vector compares return vectors and in the xl case
all vector compares return scalars.

This patch does not change the default behavior of clang.

This option will be used in future patches to implement behaviour compatibility for the vector bool/pixel types.

Reviewed By: bmahjour

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

Users can call HwasanThreadList::GetRingBufferSize rather than RingBufferSize
to prevent having to do the calculation in RingBufferSize. This will be useful
for Fuchsia where we plan to initialize the stack ring buffer separately from
the rest of thread initialization.

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

llvm-readobj is an internal testing tool for binary formats. Its output and
command line options do not need to be stable. It isn't supposed to be part of a
build process.

llvm-readelf was created as a user-facing utility and its interface intends to
be compatible with GNU readelf (unless there are good reasons not to).

The two tools have mostly compatible options. -s and -t are noticeable
exceptions due to history. I think the cost of keeping the inconsistency
overweighs the little history-compatible benefit and hinders transition from
cl::opt to OptTable, so let's change it.

Reviewed By: jhenderson

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

We can reuse the same implementation for getting the current thread on fuchsia.

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

-s and -t will be changed to improve consistency with llvm-readelf.
The inconsistency issue regularly contributes to confusion using the two tools.

The code was previously relying on the fact that an incorrectly
typed global would result in the insertion of a BitCast constant
expression. With opaque pointers, this is no longer the case, so
we should check the type explicitly.

An ARM64_RELOC_ADDEND relocation reuses the symbol field for the addend value.
We should pass through such relocations.

Reviewed By: alexander-shaposhnikov

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

Currently, LLParser will create a Function/GlobalVariable forward
reference based on the desired pointer type and then modify it when
it is declared. With opaque pointers, we generally do not know the
correct type to use until we see the declaration.

Solve this by creating the forward reference with a dummy type, and
then performing a RAUW with the correct Function/GlobalVariable when
it is declared. The approach is adopted from
https://github.com/TNorthover/llvm-project/commit/b5b55963f62038319fa7a8b1b232226ba1d8ef3c.

This results in a change to the use list order, which is why we see
test changes on some module passes that are not stable under use list
reordering.

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

[LegalizeTypes][VE] Don't Expand BITREVERSE/BSWAP during type legalization promotion if they will be promoted for NVT in op legalization.

We were trying to expand these if they were going to be expanded
in op legalization so that we generated the minimum number of
operations. We failed to take into account that NVT could be
promoted to another legal type in op legalization.

Hoping this fixes the issue on the VE target reported as a follow
up to D96681. The check line changes were taken from before
1e46b6f4 so this patch does
appear to improve some cases that had previously regressed.

When we check whether the Objective-C SPI is available, we need to check
for the mangled symbol name. Unlike `objc_copyRealizedClassList`, which
is C exported, the `nolock` variant is not.

Differential revision: https://reviews.llvm.org/D105136

While we can debate on the value of passing by const value, there is no
arguing that it's confusing to do so in some circumstances, such as when
marking a pointer parameter as being const (did you mean a pointer-to-const?).
This commit fixes a few issues along those lines.

Similar to
commit bc044a88 ("[Inline] prevent inlining on stack protector mismatch")

The noprofile function attribute is meant to prevent compiler
instrumentation from being inserted into a function. Inlining may defeat
the developer's intent. If the caller and callee don't either BOTH have
the attribute or BOTH lack the attribute, suppress inline substitution.

This matches behavior being proposed in GCC:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573511.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223

Add LangRef entry for noprofile fn attr, similar to text added in D93422
and D104944.

Reviewed By: MaskRay, melver, phosek

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

[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options

Reviewed By: aaron.ballman

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

the call already has the operand bundle

This bug was causing the call to `replaceAllUsesWith` to crash because
the old call instruction and the new call instruction were the same.

rdar://74957948

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

After SLP + LTO we may have have reduction(shuffle V, poison,
mask). This can be simplified to just reduction(V) if the mask is only
for single vector and just all elements from this vector are permuted,
  without reusing, replacing with undefs and/or other values, etc.

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

Add

    REQUIRES: shell

to the unpack.f90 test that executes a UNIX shell script.

I didn't get around to fix this change and the original commit itself seems
fine, so this looks like an existing LLDB/Clang bug that was just uncovered
by this change. Skipping while I'm investigating.

[RISCV] Protect the SHL/SRA/SRL handlers in LowerOperation against being called for an illegal i32 shift amount.

It seems it is possible for DAG combine to create a shl with an
i64 result type and an i32 shift amount. This is ok before type
legalization since the type don't need to match in SelectionDAG.
This results in type legalization calling LowerOperation to
legalize just the amount. We weren't expecting this so we
asserted for not finding a fixed vector shift.

To fix this, I've added a check for the fixed vector case and
returned SDValue() to get the default type legalizer. I've
factored all shifts together and added a fixed vector specific
handler to avoid repeating similar code for each in
LowerOperation.

The particular case I found was exposed by D104581, but the bad
shift is created after that patch triggers.

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

Depends On D104998

Function calls "transfer ownership" to the callee and it puts additional constraints on the reference counting optimization pass

Reviewed By: mehdi_amini

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

Depends On D104891

Outlining scf.parallel body as a function requires async-parallel-for pass to be a ModuleOp pass

Reviewed By: bondhugula

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

[mlir:Async] Remove async operations if it is statically known that the parallel operation has a single compute block

Depends On D104850

Add a test that verifies that canonicalization removes all async overheads if it is statically known that the scf.parallel operation will be computed using a single block.

Reviewed By: herhut

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