[analyzer] Deprecate the unused 'analyzer-opt-analyze-nested-blocks' cc1 flag

This flag was introduced by
https://github.com/llvm/llvm-project/commit/6818991d7165f68fe196922d9e5c6648dd57cc47
    commit 6818991d7165f68fe196922d9e5c6648dd57cc47
    Author: Ted Kremenek <kremenek@apple.com>
    Date:   Mon Dec 7 22:06:12 2009 +0000

  Add clang-cc option '-analyzer-opt-analyze-nested-blocks' to treat
  block literals as an entry point for analyzer checks.

The last reference was removed by this commit:
https://github.com/llvm/llvm-project/commit/5c32dfc5fb1cfcff8ae3671284e17daa8da3a188

    commit 5c32dfc5fb1cfcff8ae3671284e17daa8da3a188
    Author: Anna Zaks <ganna@apple.com>
    Date:   Fri Dec 21 01:19:15 2012 +0000

  [analyzer] Add blocks and ObjC messages to the call graph.
  This paves the road for constructing a better function dependency graph.
  If we analyze a function before the functions it calls and inlines,
  there is more opportunity for optimization.
  Note, we add call edges to the called methods that correspond to
  function definitions (declarations with bodies).

Consequently, we should remove this dead flag.
However, this arises a couple of burning questions.
 - Should the `cc1` frontend still accept this flag - to keep
   tools/users passing this flag directly to `cc1` (which is unsupported,
   unadvertised) working.
 - If we should remain backward compatible, how long?
 - How can we get rid of deprecated and obsolete flags at some point?

Reviewed By: martong

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

[mlir] add a dynamic user-after-parent-freed transform dialect check

In the transform dialect, a transform IR handle may be pointing to a payload IR
operation that is an ancestor of another payload IR operation pointed to by
another handle. If such a "parent" handle is consumed by a transformation, this
indicates that the associated operation is likely rewritten, which in turn
means that the "child" handle may now be associated with a dangling pointer or
a pointer to a different operation than originally. Add a handle invalidation
mechanism to guard against such situations by reporting errors at runtime.

Reviewed By: springerm

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

[analyzer][NFC] Remove unused RegionStoreFeatures

Reviewed By: martong

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

[flang][driver] Make `flang-new -fc1` accept MLIR files

This relatively small change will allow Flang's frontend driver,
`flang-new -fc1`, to consume and parse MLIR files.  Semantically (i.e.
from user's perspective) this is identical to reading LLVM IR files.

Two file extensions are associated with MLIR files: .fir and .mlir. Note
that reading MLIR files makes only sense when running one of the
code-generation actions, i.e. when using one of the following action
flags: -S, -emit-obj, -emit-llvm, -emit-llvm-bc.

The majority of tests that required `tco` to run are updated to also run
with `flang-new -fc1`. A few tests are updated to use `fir-opt` instead
of `tco` (that's the preferred choice when testing a particular MLIR
pass). basic-program.fir is not updated as that test is intended to
verify the behaviour of `tco` specifically.

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

[analyzer] Deprecate `-analyzer-store region` flag

I'm trying to remove unused options from the `Analyses.def` file, then
merge the rest of the useful options into the `AnalyzerOptions.def`.
Then make sure one can set these by an `-analyzer-config XXX=YYY` style
flag.
Then surface the `-analyzer-config` to the `clang` frontend;

After all of this, we can pursue the tablegen approach described
https://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488

In this patch, I'm proposing flag deprecations.
We should support deprecated analyzer flags for exactly one release. In
this case I'm planning to drop this flag in `clang-16`.

In the clang frontend, now we won't pass this option to the cc1
frontend, rather emit a warning diagnostic reminding the users about
this deprecated flag, which will be turned into error in clang-16.

Unfortunately, I had to remove all the tests referring to this flag,
causing a mass change. I've also added a test for checking this warning.

I've seen that `scan-build` also uses this flag, but I think we should
remove that part only after we turn this into a hard error.

Reviewed By: martong

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

[FuncSpec]Fix assertion failure when value is not added to solver

This patch improves the fix in D110529 to prevent from crashing on value
with byval attribute that is not added in SCCP solver.

Authored-by: sinan.lin@linux.alibaba.com
Reviewed By: ChuanqiXu

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

[AMDGPU][MC][GFX1013] Enable image_msaa_load

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

[gn build] Port ff6d5dee713c

[gn build] Port 1972d1e86a62

[flang][driver] Fix support for `-x`

Until now, `-x` wasn't really taken into account in Flang's compiler and
frontend drivers. `flang-new` and `flang-new -fc1` only recently gained
powers to consume inputs other than Fortran files and that's probably
why this hasn't been noticed yet.

This patch makes sure that `-x` is supported correctly and consistently
with Clang. To this end, verification is added when reading LLVM IR
files (i.e. IR modules are verified with `llvm::verifyModule`). This
way, LLVM IR parsing errors are correctly reported to Flang users. This
also aids testing.

With the new functionality, we can verify that `-x ir` breaks
compilation for e.g. Fortran files and vice-versa. Tests are updated
accordingly.

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

[ARM] Fix how size-0 bitfields affect homogeneous aggregates.

By both AAPCS32 and AAPCS64, the test for whether an aggregate
qualifies as homogeneous (either HFA or HVA) is based on the data
layout alone. So any logical member of the structure that does not
affect the data layout also should not affect homogeneity. In
particular, an empty bitfield ('int : 0') should make no difference.

In fact, clang considered it to make a difference in C but not in C++,
and justified that policy as compatible with gcc. But that's
considered a bug in gcc as well (at least for Arm targets), and it's
fixed in gcc 12.1.

This fix mimics gcc's: zero-sized bitfields are now ignored in all
languages for the Arm (32- and 64-bit) ABIs. But I've left the
previous behaviour unchanged in other ABIs, by means of adding an
ABIInfo::isZeroLengthBitfieldPermittedInHomogeneousAggregate query
method which the Arm subclasses override.

Reviewed By: lenary

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

[gn build] (manually) port 6bc8163c79fd

[analyzer] Print the offending function at EndAnalysis crash

I've faced crashes in the past multiple times when some
`check::EndAnalysis` callback caused some crash.
It's really anoying that it doesn't tell which function triggered this
callback.

This patch adds the well-known trace for that situation as well.
Example:
  1.      <eof> parser at end of file
  2.      While analyzing stack:
          #0 Calling test11

Note that this does not have tests.
I've considered `unittests` for this purpose, by using the
`ASSERT_DEATH()` similarly how we check double eval called functions in
`ConflictingEvalCallsTest.cpp`, however, that the testsuite won't invoke
the custom handlers. Only the message of the `llvm_unreachable()` will
be printed. Consequently, it's not applicable for us testing this
feature.

I've also considered using an end-to-end LIT test for this.
For that, we would need to somehow overload the `clang_analyzer_crash()`
`ExprInspection` handler, to get triggered by other events than the
`EvalCall`. I'm not saying that we could not come up with a generic way
of causing crash in a specific checker callback, but I'm not sure if
that would worth the effort.

Reviewed By: martong

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

[MVE] Fold fadd(select(..., +0.0)) into a predicated fadd

We already have patterns for matching fadd(select(..., -0.0)),
but an upcoming patch will lead to patterns using +0.0 as the
identity instead of -0.0. I'm adding support for these patterns
now to avoid any regressions for MVE.

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

[libc++] Granularize even more of type_traits

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

[libc++] Implement ranges::replace{, _if}

Reviewed By: var-const, #libc

Spies: libcxx-commits, mgorny

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

[LoopInfo] Add getOutermostLoop() (NFC)

This is a recurring pattern, add an API function for it.

[AggressiveInstcombine] Conditionally fold saturated fptosi to llvm.fptosi.sat

This adds a fold for aggressive instcombine that converts
smin(smax(fptosi(x))) into a llvm.fptosi.sat, providing that the
saturation constants are correct and the cost of the llvm.fptosi.sat is
lower.

Unfortunately, a llvm.fptosi.sat cannot always be converted back to a
smin/smax/fptosi. The llvm.fptosi.sat intrinsic is more defined that the
original, which produces poison if the original fptosi was out of range.
The llvm.fptosi.sat will saturate any value, so needs to be expanded to
a fptosi(fpmin(fpmax(x))), which can be worse for codegeneration
depending on the target.

So this change thais conditional on the backend reporting that the
llvm.fptosi.sat is cheaper that the original smin+smax+fptost.  This is
a change to the way that AggressiveInstrcombine has worked in the past.
Instead of just being a canonicalization pass, that canonicalization can
be dependant on the target in certain specific cases.

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

[lldb] [test] Implement getting thread ID on FreeBSD

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D126982

[mlir][bufferize] Avoid tensor copies when the data is not read

There are various shortcuts in `BufferizationState::getBuffer` that avoid a buffer copy when we just need an allocation (and no initialization). This change adds those shortcuts to the TensorCopyInsertion pass, so that `getBuffer` can be simplified in a subsequent change.

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

[bazel] Change references to driver-template.cpp.in after 6bc8163c79fd

[Documentation] Fixed typos in LibASTMatchers tutorial

There was one missing parenthesis and a typo in the mentioned
part of the documentation.

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

[libc][math] Improved FBits performance and readablity.

Some function added in preparation to fmod commit.

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

[clang][ASTImporter] Fix import of function with auto return type.

Fix a case of importing a function with auto return type
that is resolved with a type template argument that is declared
inside the function.
Fixes #55500

Reviewed By: martong

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

[libc][math] Differential "diff" test for hypot/hypotf functions.

Added test handler in preparation to fmod/fmodf commit.

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

[EarlyCSE] Update tests to use opaque pointers (NFC)

Update the EarlyCSE tests to use opaque pointers.

Worth noting that this leaves some bitcast ptr to ptr instructions
in the input IR behind which are no longer necessary. This is
because these use numbered instructions, so it's hard to drop them
in an automated fashion (as it would require renumbering all other
instructions as well). I'm leaving that as a problem for another day.

The test updates have been performed using
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34.

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

[cmake] Export driver template to fix standalone build

Export the driver-template.cpp.in file so that tools using
GENERATE_DRIVER work in standalone builds (currently only relevant
for clang). I've given the file an llvm- prefix, as we're now
searching for the file in CMAKE_MODULE_PATH.

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

[CGP] Also freeze ctlz/cttz operand when despeculating

D125887 changed the ctlz/cttz despeculation transform to insert
a freeze for the introduced branch on zero. While this does fix
the "branch on poison" issue, we may still get in trouble if we
pick a different value for the branch and for the ctz argument
(i.e. non-zero for the branch, but zero for the ctz). To avoid
this, we should use the same frozen value in both positions.

This does cause a regression in RISCV codegen by introducing an
additional sext. The DAG looks like this:

    t0: ch = EntryToken
        t2: i64,ch = CopyFromReg t0, Register:i64 %3
      t4: i64 = AssertSext t2, ValueType:ch:i32
    t23: i64 = freeze t4
          t9: ch = CopyToReg t0, Register:i64 %0, t23
          t16: ch = CopyToReg t0, Register:i64 %4, Constant:i64<32>
        t18: ch = TokenFactor t9, t16
            t25: i64 = sign_extend_inreg t23, ValueType:ch:i32
          t24: i64 = setcc t25, Constant:i64<0>, seteq:ch
        t28: i64 = and t24, Constant:i64<1>
      t19: ch = brcond t18, t28, BasicBlock:ch<cond.end 0x8311f68>
    t21: ch = br t19, BasicBlock:ch<cond.false 0x8311e80>

I don't see a really obvious way to improve this, as we can't push
the freeze past the AssertSext (which may produce poison).

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

[AMDGPU] New GFX11 intrinsic llvm.amdgcn.s.sendmsg.rtn

Add new intrinsic and codegen support for the s_sendmsg_rtn_b32 and
s_sendmsg_rtn_b64 instructions.

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

[AMDGPU] Update dlc usage for GFX11

In GFX10 dlc controlled L1 cache bypass. In GFX11 it has been repurposed
to control MALL NOALLOC, and glc controls L1 as well as L0 cache bypass.

Update the documentation and SIMemoryLegalizer accordingly. Set dlc for
nontemporal and volatile accesses.

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

[AMDGPU] Add GFX11 documentation to AMDGPUUsage

Update most of the document to include GFX11. Memory model changes will
come later.

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

[flang][NFC] Move Todo.h from Lower to Optimizer

Remove a backwards dependence from Optimizer -> Lower by moving Todo.h
to the optimizer and out of lowering.

This patch is part of the upstreaming effort from fir-dev branch.

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Reviewed By: jeanPerier

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

[JITLink][EHFrameSupport] Remove CodeAlignmentFactor and DataAlignmentFactor validation.

Removes CodeAlignmentFactor and DataAlignmentFactor validation in EHFrameEdgeFixer. I observed some of aarch64 elf files generated by clang contains CIE record with code_alignment_factor = 4 or data_alignment_factor = -8. code_alignment_factor and  data_alignment_factor are used by call fram instruction that should be correctled handled by libunwind.

Reviewed By: lhames

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

Fix bazel BUILD.

Fixes assertion that arose from bad FIR being constructed.

* Fix assertion strings.

* Fixes assertion that arose from bad FIR being constructed.

With the default member-wise component assignment, the LHS and RHS may
be compatible but distinct types. This change to lowering manages both
the LHS and RHS independently rather than assume the two types are
identical. This avoids creating bogus FIR and asserting/crashing in
codegen.

Update the tests with the member-wise copy code.

This patch is part of the upstreaming effort from fir-dev branch.

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Reviewed By: jeanPerier

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

[clang-tidy][NFC] Tweak identifier-naming options reading/writiing

[RISCV] Lower VLEFF/VLSEGFF SDNodes to MachineInstrs with VL outputs.

The patch is a replacement of D125199. PseudoReadVL with vtype has worry for
computing same vtypes of VLEFF/VLSEGFF in two different places, DAGToDAG and
InsertVSETVLI. VLEFF/VLSEGFF MI with VL output still could provide the vtype of
VLEFF/VLSEGFF to the users of its VL.

The patch names the new pseudo as original VLEFF/VLSEGFF name suffixed "_VL" and
expand them in RISCVInsertVSETVLI pass.

This patch also reverts commit 4537aae0d57e17c217c192d8977012ba475b130c,
"[RISCV] Make PseudoReadVL have the vtypes of the corresponding VLEFF/VLSEGFF.".

Reviewed By: reames

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

[ORC][ORC_RT] Handle ELF .init_array with non-default priority

ELF-based platforms currently support defining multiple static
initializer table sections with differing priorities, for example
.init_array.0 or .init_array.100; the default .init_array corresponds
to a priority of 65535. When building a shared library or executable,
the system linker normally sorts these sections and combines them into
a single .init_array section. This change adds the capability to
recognize ELF static initializers with priorities other than the
default, and to properly sort them by priority, to Orc and the Orc
runtime.

Reviewed By: lhames

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

[ORC][ORC_RT] Integrate ORC platforms with LLJIT and lli

This change enables integrating orc::LLJIT with the ORCv2
platforms (MachOPlatform and ELFNixPlatform) and the compiler-rt orc
runtime. Changes include:

- Adding SPS wrapper functions for the orc runtime's dlfcn emulation
  functions, allowing initialization and deinitialization to be invoked
  by LLJIT.

- Changing the LLJIT code generation default to add UseInitArray so
  that .init_array constructors are generated for ELF platforms.

- Integrating the ORCv2 Platforms into lli, and adding a
  PlatformSupport implementation to the LLJIT instance used by lli which
  implements initialization and deinitialization by calling the new
  wrapper functions in the runtime.

Reviewed By: lhames

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

[JITLink][ELF][AArch64] Implement Procedure Linkage Table.

Implements Procedure Linkage Table (PLT) for ELF/AARCH64. The aarch64 linux calling convention also uses r16 as the intra-procedure-call scratch register same as MachO/ARM64. We can use the same stub sequence for this reason.

Also, BR regiseter doesn't touch X30 register. External function call by BL instruction (touched by CALL26 relocation) will set X30 to the original PC + 4, which is the intended behavior. External function call by B instruction (touched by JUMP26 relocation) doesn't requite to set X30, so the patch will be correct in this case too.

Reference: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#611general-purpose-registers

Reviewed By: lhames

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

[clang-format][NFC] Remove unused FormatStyle members

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

Also move WeakRefReferences in CodeGenModule::moveLazyEmssionStates

I forgot this field in b8f9459715815fa055b3e1c5f970c616797dfcfb
Signed-off-by: Jun Zhang <jun@junz.org>

[ORC][AArch64] Add initial support for aarch64 in ELFNixPlatform.

Adds the aarch64 support in ELFNixPlatform. These are few simple changes, but it allows us to use the orc runtime in ELF/AARCH64 backend. It succesfully run the static initializers of stdlibc++ iostream so that "cout << Hello world" testcase starts to work.

Reviewed By: lhames

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

[InstCombine] Add negative vector tests for lshr+shl+and/shl+lshr+and transforms; NFC

[InstCombine] Add baseline tests for lshr+shl+and transforms; NFC

[mlir] fix typo in AttributesAndTypes doc

[JITLink][ELF][AArch64] Implement R_AARCH64_JUMP26

Implements R_AARCH64_JUMP26. We can use the same generic aarch64 Branch26 edge since B instruction and BL nstruction have the same sized&offseted immediate field, and the relocation address calculation is the same.

Reference: ELF for the ARM ® 64-bit Architecture Tabel 4-10, ARM Architecture Reference Manual ® ARMv8, for ARMv8-A architecture profile C6.2.24, C6.2.31

Reviewed By: sgraenitz

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

 [InstCombine] Optimize shl+lshr+and conversion pattern

if `C1` and `C3` are pow2 and `Log2(C3)+C2 < BitWidth`:
    ((C1 << X) >> C2) & C3 -> X == (Log2(C3)+C2-Log2(C1)) ? C3 : 0;

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

Fix issue https://github.com/llvm/llvm-project/issues/55739

Reviewed By: spatel

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

[JITLink][AArch64] Fix overflow range of Page21 fixup edge.

Allowed range for Page21 relocation is -2^32 <= X < 2^32 in both ELF and MachO.

https://github.com/llvm/llvm-project/blob/09c2b7c35af8c4bad39f03e9f60df8bd07323028/llvm/lib/ExecutionEngine/RuntimeDyld/Targets/RuntimeDyldMachOAArch64.h#L210 (MachO)

ELF for the ARM ® 64-bit Architecture (AArch64) Table 4-9 (ELF)

Reviewed By: sgraenitz

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

[libc][math] Separated builtin function in special FPUtils header.

A small refactoring of builtin functions in preparation to adding fmod/fmodf function.

Reviewed By: lntue

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

[lld][WebAssembly] Revert moving of data relocations to start function

Back in https://reviews.llvm.org/D117412 we moved the application of
data reloctions to the wasm start function.

However, because the dynamic linker doesn't know the final addresses
at module instantiation time, this proved to be too early and the
relocations could be applied with the wrong values.

Fixes: https://github.com/emscripten-core/emscripten/issues/17150

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

[flang] semantics test for ucobound

Add a test with a range of ucobound() intrinsic function
invocations, including a comprehensive set of standard-conforming
keyword and non-keyword arguments with and without optional
arguments present and with argument positions covering all
possible orderings.  Also test that several non-conforming
ucobound() invocations generate the correct error messages.

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

[RISCV] Simplify InstrInfo access in doPeepholeMaskedRVV [nfc]

[mlir][NFC] Rename Bazel target aliases and consolidate targets

This patch completes outstanding TODOs of removing aliases bazel target names.
This patch also renames and cosolidates some bazel targets to be more in line
with their CMake counterparts, e.g. combining `:LinalgOps` and `:LinalgInterfaces`
into `:LinalgDialect`.

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

[mlir] Support passing ostream as argument for the create function.

The constructor already supports passing an ostream as argument,
so let's make the create function support it too.

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

[NFC] test commit

This is an empty commit to check commit access

[lldb] Use assertState in more tests (NFC)

Follow to D127355, converting more `assertEquals` to `assertState`.

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

[mlir][spirv] Replace StructAttrs with AttrDefs

Depends on D127370

Reviewed By: antiagainst

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

[BasicTTI] Return Invalid cost for more scalable vector scalarization cases

Instead of crashing on a cast<FixedVectorType>, we should isntead return Invalid for these cases.  This avoids crashes in assert builds, and potential miscompiles in release builds.

[RISCV] Teach RISCVMergeBaseOffset about cases where we use SHXADD to add some immediates.

For an addition with simm14 and simm15 immediates with 2 or 3 trailing bits,
we can use a shXadd instruction and an addi to do the addition.

This patch teaches RISCVMergeBaseOffset to see through this pattern.
I don't think the sh1add case occurs because we use two addis for that,
but I implemented it for completeness.

Reviewed By: reames

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

[mlir][tosa] Replace StructAttrs with AttrDefs

Depends on D127352

Reviewed By: rriddle

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

[mlir][gpu] Move GPU headers into IR/ and Transforms/

Depends on D127350

Reviewed By: rriddle

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

Plumb InstructionCost through unroll costing

Teach the unroller(s) how to handle an invalid cost. This avoids crashes when the backend can't provide a cost due to either a fundemental limitation or an unimplemented cost model case.

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

[BOLT][AArch64] Handle data at the beginning of a function when disassembling and building CFG.

This patch adds getFirstInstructionOffset method for BinaryFunction
which is used to properly handle cases where data is at zero offset in
a function. The main change is that we add basic block at first
instruction offset when disassembling, which prevents assertion
failures in buildCFG.

Reviewed By: yota9, rafauler

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

[mlir][gpu] Change ParalellLoopMappingAttr to AttrDef

It was a StructAttr. Also adds a FieldParser for AffineMap.

Depends on D127348

Reviewed By: rriddle

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

Pipe potentially invalid InstructionCost through CodeMetrics

Per the documentation in Support/InstructionCost.h, the purpose of an invalid cost is so that clients can change behavior on impossible to cost inputs. CodeMetrics was instead asserting that invalid costs never occurred.

On a target with an incomplete cost model - e.g. RISCV - this means that transformations would crash on (falsely) invalid constructs - e.g. scalable vectors. While we certainly should improve the cost model - and I plan to do so in the near future - we also shouldn't be crashing. This violates the explicitly stated purpose of an invalid InstructionCost.

I updated all of the "easy" consumers where bailouts were locally obvious. I plan to follow up with loop unroll in a following change.

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

[mlir][nvvm] Change MMAShapeAttr to AttrDef

MMAShapeAttr was a StructAttr

Reviewed By: rriddle

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

[gn build] (manually) port 25c8a061c573

[libc] move printf_main in to object library

Previously printf_main was a header library, but header library
dependencies don't work properly so it's been moved to an object
library. Additionally, the writers have been marked inline.

Reviewed By: sivachandra, lntue

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

[pseudo] Fix the broken build of ClangPseudoBenchmark, after c70aeaa.

[InstCombine] add narrowing transform for low-masked binop with zext operand

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

As shown in D123408, we can produce this pattern when moving
cast around, and we already have a related fold for a binop
with a constant operand.

[InstCombine] add tests for masked binop narrowing; NFC

[AggressiveInstcombine] Add target tests for fptosi.sat fold. NFC

[bazel] Add missing dependency after 9f1221521f4b.

[X86] Remove !VT.is128BitVector() check. NFCI.

The code is inside a if(VT.is256BitVector() || VT.is512BitVector()) condition

[BOLT] Add support for GOTPCRELX relocations

The linker can convert instructions with GOTPCRELX relocations into a
form that uses an absolute addressing with an immediate. BOLT needs to
recognize such conversions and symbolize the immediates.

Reviewed By: rafauler

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

[AMDGPU] Update SIInsertHardClauses for GFX11

Changes for GFX11:
- Clauses may not mix instructions of different types, and there are
  more types. For example image instructions with and without a sampler
  are now different types.
- The max size of a clause is explicitly documented as 63 instructions.
  Previously it was implicitly assumed to be 64. This is such a tiny
  difference that it does not seem worth making it conditional on the
  subtarget.
- It can be beneficial to clause stores as well as loads.

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

[mlir][bufferize] Improve resolveConflicts for ExtractSliceOp

It is sometimes better to make a copy of the OpResult instead of making a copy of the OpOperand. E.g., when bufferizing tensor.extract_slice.

This implementation will eventually make parts of extract_slice's `bufferize` implementation obsolete (and simplify it). It will only need to handle in-place OpOperands.

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

[X86][AVX2] LowerINSERT_VECTOR_ELT - support v4i64 insertion as BLENDI(X, SCALAR_TO_VECTOR(Y))

[mlir][bufferization][NFC] Put inplacability conflict resolution in op interface

The TensorCopyInsertion pass resolves out-of-place bufferization decisions by inserting explicit `bufferization.alloc_tensor` ops. This change moves that functionality into a new BufferizableOpInterface method, so that it can be overridden by op implementations. Some op bufferizations must insert additional `alloc_tensor` ops to make sure that certain aliasing invariants are not violated (e.g., scf::ForOp). This will be addressed in a subsequent change.

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

Recommit "[mlir][vector] Allow unroll of contraction in arbitrary order"

Fixed issue with vector.contract default unroll permutation.

Adds support for vector unroll transformations to unroll in different
orders. For example, the vector.contract can be unrolled into a
smaller set of contractions. There is a choice of how to unroll the
decomposition based on the traversal order of (dim0, dim1, dim2).
The choice of traversal order can now be specified by a callback which
given by the caller of the transform. For now, only the
vector.contract, vector.transfer_read/transfer_write operations
support the callback.

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

[Object][COFF] Fix section name parsing error when the name field is not null-padded

Some object files produced by Mirosoft tools contain sections whose name field
is not fully null-padded at the end. Microsoft's dumpbin is able to print the
section name correctly, but this causes parsing errors with LLVM tools.

So far, this issue only seems to happen when the section name is longer than 8
bytes. In this case, the section name field contains a slash (/) followed by the
offset into the string table, but the name field is not fully null-padded at the
end.

Reviewed By: mstorsjo

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

[libc++] Fixes CI after Jammy update.

Reviewed By: #libc, philnik

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

[mlir][bufferization] Add TensorCopyInsertion pass

This pass runs the One-Shot Analysis to find out which tensor OpOperands must bufferize out-of-place. It then rewrites those tensor OpOperands to explicit allocations with a copy in the form of `bufferization.alloc_tensor`. The resulting IR can then be bufferized without having to care about read-after-write conflicts.

This change makes it possible to connect One-Shot Analysis to other bufferizations such as the sparse compiler.

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

[Sanitizers] Cleanup handling of stat64/statfs64

There are differences in handling of stat64/statfs64 calls by sanitizers between Linux and macOS. Versions of macOS starting with 10.6 drop the stat64/statfs64 APIs completely, relying on the linker to redirect stat/statfs to the appropriate 64 bit versions. Emitting variables needed by sanitizers is thus controlled by convoluted sets of conditions, involving Linux, IOS, macOS and Android, sprinkled around files.

This change adresses it, allowing to specify presence/absence of stat64/statfs64 for each platform, in a single location. Also, it adresses the Android case which handles stat64, but not statfs64.

Adding Vitaly as a reviewer since he seems to be actively working on sanitizers, perhaps can comment on the Android bit

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

[libc++] Mark GDB pretty printers as unsupported on GCC 11.2 to make CI green

[AMDGPU] gfx11 VOPC instructions

Supports encoding existing instrutions on gfx11 and MC support for the new VOPC
dpp instructions.

Patch 19/N for upstreaming of AMDGPU gfx11 architecture

Depends on D126978

Reviewed By: rampitec, #amdgpu

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

[lldb] Set COFF module ABI from default triple and make it an option

PE/COFF can use either MSVC or GNU (MinGW) ABI for C++ code, however
LLDB had defaulted to MSVC implicitly with no way to override it. This
causes issues when debugging modules built with the GNU ABI, sometimes
even crashes.

This changes the PE/COFF plugin to set the module triple according to
the default target triple used to build LLDB. If the default target
triple is Windows and a valid environment is specified, then this
environment will be used for the module spec. This not only works for
MSVC and GNU, but also other environments.

A new setting, `plugin.object-file.pe-coff.abi`,  has been added to
allow overriding this default ABI.

* Fixes https://github.com/llvm/llvm-project/issues/50775
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/226
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/282

Reviewed By: omjavaid

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

[mlir][bufferization] Add optional `copy` operand to AllocTensorOp

If `copy` is specified, the newly allocated buffer is initialized with the given contents. Also add an optional `escape` attribute to indicate whether the buffer of the tensor may be returned from the parent block (aka. "escape") after bufferization.

This change is in preparation of connecting One-Shot Bufferize to the sparse compiler.

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

[LLD] [ELF] Add parentheses to silence a GCC warning. NFC.

This silences the following warning:

../tools/lld/ELF/SyntheticSections.cpp:1596:48: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
 1596 |   assert((index != 0 || type != target->gotRel && type != target->pltRel ||

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

[libcxx] [doc] Add a release note for distributors about MinGW builds and dllimport

This allows distributors to simplify how libc++ is built in MinGW
configurations.

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

Reapply: Add an error message to the default SIGPIPE handler

UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to exit
and thus automatically on a return from main. Write failure is then
detected by LLVM's default SIGPIPE handler. The handler already exits with
a non-zero code, but conformance additionally requires an error message.

First reapply attempt I hadn't noticed the test had changed, hopefully this
goes better.

[gn build] Port 976f37050dbd

[libc++] Granularize __string

Reviewed By: ldionne, #libc

Spies: libcxx-commits, mgorny

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

[AMDGPU] Use v_mad_u64_u32 for IMAD32

Nic Curtis done the experiments to prove it is faster than a
separate mul and add.

Fixes: SWDEV-332806

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

[mlir][sparse] refactor handling of merger leafs and ops

Using "default:" in the switch statemements that handle all our
merger ops has become a bit cumbersome since it is easy to overlook
parts of the code that need to handle ops specifically. By enforcing
full switch statements without "default:", we get a compiler warning
when cases are overlooked.

Reviewed By: wrengr

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

Revert "Add an error message to the default SIGPIPE handler"

It broke PPC bots.

[BOLT][DWARF] Fix dwarf5-loclist-offset-form test

I put it into wrong directory. As the result it is failing for aarch64. Moving
the test under X86. Orignial diff D126999.

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

[SystemZ/z/OS] Fix failing dynamic library unit test.

Root cause for the failure is that the visibility of symbols
is different on z/OS. To fix the failure, the symbols need to
be exported.

Reviewed By: abhina.sreeskantharajan

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

[AMDGPU] Fix hazard handling of v_cmpx to permlane

- VOP3 and SDWA forms of V_CMPX were not handled
- Hazard only exists if the compare defines EXEC (i.e. V_CMPX)
  forwarded to the permlane.

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