[mlir][Python] Add a simple PyOpOperand iterator for PyValue uses.

This adds a simple PyOpOperand based on MlirOpOperand, which can has
properties for the owner op and operation number.

This also adds a PyOpOperandIterator that defines methods for __iter__
and __next__ so PyOpOperands can be iterated over using the the
MlirOpOperand C API.

Finally, a uses psuedo-container is added to PyValue so the uses can
generically be iterated.

Depends on D139596

Reviewed By: stellaraccident, jdd

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

[OpenMP][Test] Make the output error message consistent with the comment

Modify the error message output of affinity/kmp-affinity.c and
affinity/omp-places.c.

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

[openmp][amdgpu] Let fine grain and kernarg pools differ

[VP][RISCV] Add vp.ctpop and RISC-V support.

The patch also adds expandVPCTPOP in TargetLowering to expand VP_CTPOP nodes.

Reviewed By: craig.topper

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

[mlir][tosa] Fix padding for tosa.conv2d and tosa.depthwise_conv2d decomposition

Decomposition did not take padding into account when decomposing into fully
connected operation.

Reviewed By: NatashaKnk

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

[flang] Fix a warning

This patch fixes:

  flang/lib/Lower/PFTBuilder.cpp:1042:6: error: function 'dumpScope'
  is not needed and will not be emitted
  [-Werror,-Wunneeded-internal-declaration]

[IPO] Fix a warning

This patch fixes:

  llvm/lib/Transforms/IPO/AttributorAttributes.cpp:1028:21: error:
  unused function 'operator<<' [-Werror,-Wunused-function]

[ubsan][test] Be more specific than "error:" with implicit-check-not

The string "error:" is too general and reports false positive from system
messages that can occur on stderr when using network devices for testing.
The string "runtime error:" is sufficiently unique for these connection
errors to pass through w/o a false positive.

rdar://100564373

Reviewed By: thetruestblue

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

[lld-macho][test][nfc] Update stabs.s to use touch -d instead of -t

The test currently uses `touch -t` (e.g., `env TZ=UTC touch -t
"197001010000.16"`) to set file timestamps. However, this does not seem to set
the time zone correctly in a singularity container. While this is probably a
bug/limitation of the singularity container, but we can instead use `touch
-d` (e.g., `touch -d "1970-01-01 00:00:16 UTC"`) to achieve the same result
without relying on a fix from singularity. Thoughts?

Reviewed By: int3, #lld-macho

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

[CMake] Setting the LLVM_TARGET_TRIPLE macro based on the LLVM_DEFAULT_TARGET_TRIPLE

After D137870, LLVM_TARGET_TRIPLE is no longer defined on the runtime
path into compiler-rt. This patch creates a common block of code to set
LLVM_TARGET_TRIPLE equal to the default for both the llvm- and runtime-
paths.

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

Revert "Reland "[compiler-rt][test] Heed COMPILER_RT_DEBUG when compiling unittests""

This reverts commit 255c3e3dcb06299aa2365f70817322a8a381c351, which
breaks Msan-x86_64-Test.

[NFC] [DirectX backend] copy dxil-dis as exe file on windows

Without .exe in the name on windows, the test not work.

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

[LSAN][NFC] Eliminated GetThreadRegistryLocked from the LSAN interface to avoid the need to implement it in HWASAN.

Reviewed By: vitalybuka

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

[mlir] Fix a warning

This patch fixes:

  mlir/lib/Dialect/Linalg/Transforms/DataLayoutPropagation.cpp:52:42:
  error: 'None' is deprecated: Use std::nullopt
  instead. [-Werror,-Wdeprecated-declarations]

[flang] Fix build failure

[X86] Don't zero out %eax if both %al and %ah are used

The iterator over super and sub registers doesn't include both 8-bit
registers in its list. So if both registers are used and only one of
them is live on return, then we need to make sure that the other 8-bit
register is also marked as live and not zeroed out.

Reviewed By: nickdesaulniers

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

[SPARC] Add GNU syntax extensions of WRPR instruction

Add two GNU extension forms of wrpr:

wrpr %reg, %rd -> wrpr %reg, %g0, %rd
wrpr  imm, %rd -> wrpr  %g0, imm, %rd

Note: since the semantics of wrpr %rs1, %rs2/imm, %rd is %rd <- (%rs1 xor %rs2/imm),
in case (1) it technically doesn't matter whether the %g0 is placed as the first or
second operand, however, I'm placing it as the second operand to match the encoding
of GNU as.

This fixes the wrpr instruction part of bug #40792

Reviewed By: arsenm

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

[llvm][Object] set SF_Hidden flag for MachO files

Reviewed By: pete, ributzka

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

Skip TestEarlyProcessLaunch.py w/ system debugserver

This test depends on having a new packet supported by debugserver;
skip it until we have a system debugserver installed on the CI bots
with this change.

[NFC][X86][Codegen] Fix test coverage for AVX512 i1 mask replication

At least some of the seemingly-bad codegen was because we really need to
consume the replicated i1 mask by the mask-consuming instruction
if we want faithful codegen for the replication shuffle.

But some of the odd codegen is still there.

Don't try to look up a name containing a dependent type.

Template instantiation can create names that are still dependent, such
as `operator T`. Don't assume that they can be looked up immediately,
and instead defer lookup for such names until we know what `T` is.

[NFC] Cleanup: Remove uses of BasicBlock::getInstList().

This is part of a series of patches that aim at making Function::getInstList() private.

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

[SPARC] Mark the %g0 register as constant & use it to materialize zeros

Materialize zeros by copying from %g0, which is now marked as constant.

This makes it possible for some common operations (like integer negation) to be
performed in fewer instructions.

This continues @arichardson's patch at D132561.

Reviewed By: arsenm

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

[mlir][tensor][linalg] Enhance pack op propagation across generic ops.

Considering the case that generic + pack (with outer_dim_perms), the
truth is that it is equipvelent to generic + pack + transpose. There are
two steps to bubble up the pack op accross the generic op.

Step 1. swap generic + pack -> pack + generic.

In this step, we can bind the packing information to dimensions of
iteration domain. With the information, we can pack the operands with
corresponding data tile sizes; the packed inner dimensions will be
appended to the indexing_maps. Note that the outer dimensions of
indexing maps are not changed at all.

Step 2. Fold the transpose into generic op.

The step two is just updating the indexing map, so we do not have to
handle outer_dim_perms anymore.

There could be step 3 to extract the transpose op out (i.e., generic ->
transpose + generic), then we can fold the transpose into the pack op.
This step is not done in the revision.

Co-authored-by: Lorenzo Chelini <l.chelini@icloud.com>
Reviewed By: chelini

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

[ValueTracking] peek through extends in haveNoCommonBitsSet (2nd try)

The 1st try was not clean because a portion of the code diff
made it into the pre-commit patch to add tests. This should
be the same end result without the muddied code diff.

Original commit message:

In cases with matching extends, this allows changing an 'add'
into an 'or' and narrowing the 'or' which then simplifies to
a constant.

In cases with opposite extends, we just convert to an 'or'
currently, but that could be reduced too.

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

[lld-macho][test] Add test case for section ordering

This covers the special section ordering handling. This chooses to fake the sections vs creating them organically which is probably a bit easier to maintain.

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

[llvm][tests] Don't run -O2 on instcombine test [NFC]

[HWASAN][NFC] Added implementation for the most of the allocator related functions from the LSAN interface.

Reviewed By: vitalybuka

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

[mlir][sparse] Make some integration tests run with vectorization.

Reviewed By: Peiming

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

[lld-macho] Fix __objc_stubs ordering

In the case of large binaries previously you could end up getting
relocation failures. This mirrors ld64's ordering of these sections. I'm
not sure this solves all cases but it should help in some.

Fixes https://github.com/llvm/llvm-project/issues/58298

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

[InstCombine] add tests for add-of-extends; NFC (2nd try)

The 1st attempt ( c8cba0bc4a8c9f ) accidentally picked up a code diff.

Revert "[InstCombine] add tests for add-of-extends; NFC"

This reverts commit c8cba0bc4a8c9f4f3f10e17f601ed924dfb82bef.
An unintended code change snuck into this (was supposed to just add tests).

Revert "[ValueTracking] peek through extends in haveNoCommonBitsSet"

This reverts commit 7520d187cf0dedcf5085f71bc1a5472c75cc8dbb.

The pre-commit patch that was supposed to NFC add tests for this
patch picked up some code that should not be here. I'll clean up
and re-commit.

[flang] Submodules

A submodule is a program unit that may contain the implementions of procedures
declared in an ancestor module or submodule.

Processing for the equivalence groups and variables declared in a submodule
scope is similar to existing processing for the equivalence groups and
variables in module and procedure scopes. However, module and procedure scopes
are tied directly to code in the Pre-FIR Tree (PFT), whereas processing for a
submodule must have access to an ancestor module scope that is guaranteed
to be present in a .mod file, but is not guaranteed to be in the PFT. This
difference is accommodated by tying processing directly to a front end scope.
Function scopes that can be processed on the fly are done that way; the
resulting variable information is never stored. Module and submodule scopes
whose symbol information may be needed during lowering of any number of module
procedures are instead cached on first use, and reused as needed.

These changes are a direct extension of current code. All module and submodule
variables in scope are processed, whether referenced or not. A possible
alternative would be to instead process symbols only when first used. While
this could ultimately be beneficial, such an approach must account for the
presence of equivalence groups. That information is not currently available
for on-the-fly variable processing.

Some additional changes are needed to include submodules in places where
modules must be considered, and to include separate module procedures in
places where other subprogram variants are considered. There is also a fix
for a bug involving the use of variables in an equivalence group in a
namelist group, which also involves scope processing code.

[ValueTracking] peek through extends in haveNoCommonBitsSet

In cases with matching extends, this allows changing an 'add'
into an 'or' and narrowing the 'or' which then simplifies to
a constant.

In cases with opposite extends, we just convert to an 'or'
currently, but that could be reduced too.

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

[InstCombine] add tests for add-of-extends; NFC

[libc] add scanf int conversions

This patch adds the integer conversions %d/i/u/o/x/X to scanf as well as
unit tests to check their correctness.

Reviewed By: sivachandra

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

[libc] fix scanf error handling

Scanf is supposed to return EOF when it fails to make any conversions
and there is an input failure. Previously it would return EOF on a
matching failure, which may be an input failure but can also be a
parsing error.

Reviewed By: sivachandra

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

[InstCombine] Fold logic-and/logic-or by distributive laws

X && Z || Y && Z --> (X || Y) && Z
https://alive2.llvm.org/ce/z/nM6kZb

(X || Z) && (Y || Z) --> (X && Y) || Z
https://alive2.llvm.org/ce/z/_EWLRR

Fix: https://github.com/llvm/llvm-project/issues/53861

Reviewed By: spatel

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

Use different export file when linking with dylib

This fixes compilation of clang with lld, as reported in
https://reviews.llvm.org/D135402.

Basically some symbols are not available when not linking statically.

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

[mlir][crunner] Add support for invoking std::sort.

Reviewed By: aartbik

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

[flang] emit warning when encountering a non-variable actual argument when its corresponding dummy argument expects a VOLATILE variable

This patch implements @klausler's suggestion in `llvm-project` [issue #58973](https://github.com/llvm/llvm-project/issues/58973); encountering the `VOLATILE` attribute should produce a __warning__, not a __fatal error__.

When tested on the following Fortran program `snem0601_012_.f90`:
```fortran
  module mod
    contains
    subroutine sub(m6,error)
    integer,intent(inout) :: error

    integer,volatile :: m6

    if (any ((/m6/).ne.(/6/))) &
   & then
       error = 1
    end if
    end subroutine
  end module

  program fe1nvol12

    use mod
    integer :: error = 0

    call sub(6,error)

    if (error .ne. 0) then
      print *,'NG: snem0601_012'
    end if

    print *,'pass: snem0601_012'

  end program fe1nvol12
```

the following output is produced:

```bash
$ flang-new -fc1 snem0601_012_.f90
/noback/93u/Sandbox/issue_58973_volatile_dummy_arg/snem0601_012_.f90:21:12: warning: actual argument associated with VOLATILE dummy argument 'm6=' is not a variable
    call sub(6,error)
             ^
```

Reviewed By: clementval, klausler

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

[bazel] Add __support_compiler_features dep in more places

[RISCV] Reuse VL (if non-zero) when building single element vector for start of reduction chain

This is an alternative patch on a path to D137530.

The basic problem being tackled here is that we need to place a scalar into lane 0 of a vector register before our reduction instructions. Since we only care about lane 0 of the vector, we can use any VL >= 1 provided that the total amount of work performed matches the work performed for a VL=1.

This change does not contain the logic from D137530 to perform the insert at the original VT, and then extract down to LMUL1. That turns out to be a good choice, as discussion in this review has indicated there are issues around LMUL2 and above with our representation of vmv.s.x. We'd also need to be careful with the splat logic for the same reasons.

The only potentially concerning codegen change I spot here is that we stop using a broadcast load (for VL=1) and instead do a scalar load and insert. I think this is probably reasonable; if reviewers disagree, I can investigate using a broadcast load which writes to the undef lanes. If we want to do that, we should do it for VECTOR_INSERT_ELT as well, so that'll end up as it's own patch series.

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

[mlir][math] Added math::FPowI conversion to calls of outlined implementations.

Power functions are implemented as linkonce_odr scalar functions
for FPowI operations met in a module.
Vector form of FPowI is linearized into a sequence of calls
of the scalar functions.

Option {min-width-of-fpowi-exponent} controls which FPowI operations
are converted by MathToFuncs: if the width of the exponent's integer
type is less than the specified value, then the operation is not converted.

Flang will specify {min-width-of-fpowi-exponent=33} to make sure that
math::FPowI operations with exponent wider than 32 bits will be converted
by MathToFuncs, and operations with more narrow exponent will be left
for MathToLLVM to convert them to LLVM::PowIOp.

Reviewed By: Mogball

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

[X86] Fix cmp order in probing BuildStackAlignAND

Due to reversed arguments, the loop start was almost always skipping the
whole loop, since FinalStackProbed is probably less than StackPtr for
large alignments. The intent was to skip the loop if the first sub on
StackPtr made it less than FinalStackProbed already, so flip it.

Reviewed By: serge-sans-paille

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

[InstCombine] Support vectors in simplifyIntToPtrRoundTripCast.

This code compares getPointerTypeSizeInBits and getTypeSizeInBits.
getPointerTypeSizeInBits contains a call to getScalarType while
getTypeSizeInBits does not. This makes the code incorrect for vectors.

For scalable vectors this caused a warning about a scalable TypeSize
being converted to unsigned.

Switch to DL.getTypeSizeInBits for the pointers too. This should
work since inttoptr/ptrtoint can't change the number of elements.
This was suggested by @nikic in D139911.

Fixes PR59480.

Reviewed By: nikic

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

[NFC] Cleanup: Remove Function::getBasicBlockList() when not required.

This is part of a series of patches that aim at making Function::getBasicBlockList() private.

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

Launch state discoverable in Darwin, use for SafeToCallFunctions

The dynamic linker on Darwin, dyld, can provide status of
the process state for a few significant points early on,
most importantly, when libSystem has been initialized and it
is safe to call functions behind the scenes.  Pipe this
information up from debugserver to DynamicLoaderMacOS, for
the DynamicLoader::IsFullyInitialized() method, then have
Thread::SafeToCallFunctions use this information.  Finally,
for the two utility functions in the AppleObjCRuntimeV2
LanguageRuntime plugin that I was fixing, call this method
before running our utility functions to collect the list of
objc classes registered in the runtime.

User expressions will still be allowed to run any time -
we assume the user knows what they are doing - but these
two additional utility functions that they are unaware of
will be limited by this state.

Differential Revision: https://reviews.llvm.org/D139054
rdar://102436092
can probably make function calls.

Reland "[mlir][arith] Add canonicalization patterns for 'mul*i_extended'"

- Add a fold for `mulsi_extended(x, 1)`
- Add folds to demote wide integer multiplication to `mul*i_extended` when the result is shifted
   and truncated: `trunci(shrui(mul(*ext(x), *ext(y)), c)) -> mul*i_extended(x, y)`

Reviewed By: Mogball, jpienaar

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

[RISCV] Use make_range instead of iterator_range for code from 8e6c3094

Jordan fixed this once in 4f9d069, but using make_range is more idiomatic than my accidental iterator_range usage, even with the template type to fix the warning.

Revert "[Propeller] Use Fixed MBB ID instead of volatile MachineBasicBlock::Number."

This reverts commit 6015a045d768feab3bae9ad9c0c81e118df8b04a.

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

[lldb] Remove basestring references in examples (NFC)

`basestring` is Python 2 only.

[mlir][Python] Add `__hash__` implementation for Block.

This allows us to hash Blocks and use them in sets or parts of larger
hashable objects. The implementation is the same as other core IR
constructs: the C API object's pointer is hashed.

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

[bazel] Add extract_api after 7a85192166b551929d413e8a38549375503371db

[NFC] Specify template type to fix -Wctad-qmaybe-unsupported

Workaround an assertion failure during module build

After the change in https://reviews.llvm.org/D131858, clang cannot
bootstrap itself with modules due to assertion failure:
(lvaluePath->getType() == elemTy && "Unexpected type reference!")

Workaround the assertion by converting some of the includes into forward
declares.

Reviewed By: arphaman

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

Revert "[mlir][sparse] Make some integration tests run with vectorization."

This reverts commit 2d7e3ec6b5e3d99de6ce79049d4bef96213109ee.

This broke buildbots [1] and I can also reproduce this locally.

[1] https://lab.llvm.org/buildbot#builders/61/builds/36953

[NFC][MC] `MCInst`: `Operands` small size optimization: store 10, not 8, inline `MCOperand`

This improves the torture test of
```
./bin/llvm-exegesis -mcpu=znver3 -mode=inverse_throughput --opcode-index=-1 --benchmarks-file=/dev/null --dump-object-to-disk=0 --measurements-print-progress --skip-measurements
```
from ~2m16s to ~2min07s, and has the following effect on memory:

```
heaptrack stats:
        allocations:            100828624 -> 77362343 (-23.2%)
        leaked allocations:     1128
        temporary allocations:  24911300  ->  1576308 (-93.7%) !!!

peak heap memory consumption:
        78.2MB after 02.121s    ->   76.4MB after 01.985s (-2.3%)
peak RSS (including heaptrack overhead):
        193.4MB                 ->   192.6MB              (-0.4%)
```

The reasoning is that having more Operands than the SSO is costly,
because we go to global allocator, but having larger SSO is fine,
even if it's not always needed, because MCInst is hopefully pool-allocated.

I'm not sure who is the code owner of this component.

Reviewed By: craig.topper

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

[NFC][Costmodel][X86] Replication shuffle: AVX512F can promote i1 to i32.

As the added codegen test coverage shows,
there isn't that much difference between AVX512DQI and
baseline AVX512F codegen, DQI added `vpmovm2d`/`vpmovd2m`,
but with just the Foundation we can use `vpternlogd`/`vptestmd`
to do the same.

[x86][Costmodel] AVX512VL: add missing costs for v8 i1<->i32 casts

This would come up as a regression in the follow-up Replication-of-i1 patch.

https://godbolt.org/z/fxr9Mzssr

[NFC][X86][Codegen] Add codegen test coverage for i1 mask replication (AVX512 only)

Apparently i didn't add it when adding cost model coverage?

[LoopFusion] sink second loop PHIs

Fixes https://github.com/llvm/llvm-project/issues/59023

PHI nodes that are in the second loop only have the first loop as its
predecessor. These PHI nodes should be sunk to the end of the fused
loop. If the second loop uses the PHI, then the loops cannot be fused.

I don't think this should happen in typical compilation workflows.
The PHI will be in a dedicated exit block of the first loop following
LCSSA transformations.

Reviewed By: aeubanks

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

[mlir][arith] Clean up arith canonicalization td rules

- Use `ConstantLikeMatcher` instead of matching `Arith_ConstantOp`
- Reflow some defs to fit the line limit

Suggested by @jpienaar and @Mogball in https://reviews.llvm.org/D139778.

Reviewed By: Mogball

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

[mlir][sparse] Make some integration tests run with vectorization.

Reviewed By: Peiming

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

[SLP][NFC]Initial redesign of ShuffleInstructionBuilder, NFC.

The patch redesigns ShuffleInstructionBuilder so it could later be used
for reshuffling of the buildvector sequences and vectorized parts of
  externally used scalars. Also will allow to generalize cost model for
  the gathers/buildvectors.

Part of D110978.

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

[mlir] Implement backward dataflow.

This enables interprocedural lifeness analysis, very busy expression
analysis, etc.

Reviewed By: Mogball

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

[opt] Do not add verify pass at beginning of pipeline

We've already verified the input module manually in opt so this is redundant.

Reviewed By: bjope

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

[StandardInstrumentations] Handle initial IR before checking if IR is interesting

Otherwise we end up in situations where we print thre initial IR after we've already printed some changed IR.

Reviewed By: jamieschmeiser

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

[RISCV] Use reduction result type for EXTRACT_VECTOR_ELT in lowerReductionSeq.

Remove the call to getSExtOrTrunc.

Reduction ISD nodes produce a scalar result and that result is
allowed to be larger than the vector element type due to type
legalization. This is the same rule we allow for EXTRACT_VECTOR_ELT
for the same reason.

We can copy the result type over from the reduction node to
EXTRACT_VECTOR_ELT.

Reviewed By: reames

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

[RISCV] Add support for call returns to RISCVSExtWRemoval.

The implementation is inspired by code from PPCInstrInfo.

We look for a copy from X10(A0) preceded by an ADJCALLSTACKUP and
a PseudoCall. We use the PseudoCall to look up the IR function being
called to find it's return attributes.

Reviewed By: asb

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

[RISCV] Use lowerScalarInsert when folding op into reduction [nfc]

This doesn't cause any functional change since this is being applied to a insert generated by the same routine.  This is mostly about consolidating the logic for vmv.s.x into one place to simplify future changes.

[RISCV] Use lowerScalarInsert in lowerReductionSeq [nfc]

Use the newly introduced helper routine.  At the moment, this generates the same code (at this call site!) since LMUL is restricted to LMUL1 or less, and VL is hard coded to 1.  In a future patch, I will loosen the second part.

[HWASAN] Implemented LsanMetadata in HWASAN.

Please note that that this code is not used. It will be connected at some point when the rest of the code is ready.

Reviewed By: vitalybuka

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

[llvm-driver] Just use argv[0]'s filename for finding tool

Usually we want the stem of argv[0] so something like clang-15
will correctly be identified as clang. For lld however, ld.lld
or ld-link would have a stem of just ld, so we also want to
use the full filename. The bug previously was that we were using
all of argv[0] so if you use a full path that happens to include a tool
name then that could be found first. This was the case in 2 stage
build where the binaries are stored in "tools/clang/stage2-bins/"
so some tools would end up as clang and not their intended tool.

[AAPointerInfo] track multiple constant offsets for each use

An expression of the form `gep(base, select(pred, const1, const2))` can result
in a set of offsets instead of just one. PointerInfo can now track these sets
instead of conservatively modeling them as Unknown. In general, AAPointerInfo
now uses AAPotentialConstantValues to examine the operands of the GEP.

Reviewed By: jdoerfert

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

[CMake] Add missing tablegen deps

[gn build] Port 233ca84a25a7

InstCombine: Add baseline tests for and/or of fcmp to class combine

This is for patterns like !isfinite || zero.

Revert "[mlir][arith] Add canonicalization patterns for 'mul*i_extended'"

This reverts commit 834c17f618ce87b14446e42250d924b8d5f01abe.

Revert to properly address post-commit comments by @jpienaar
under https://reviews.llvm.org/D139778.

[NVPTX] Backend support for variadic functions

This patch adds lowering for function calls with variadic number of
arguments as well as enables support for the following
instructions/intrinsics:

  - va_arg
  - va_start
  - va_end
  - va_copy

Note that this patch doesn't intent to include clang's support for
variadic functions for CUDA.

According to the docs:

  PTX version 6.0 supports passing unsized array parameter to a
  function which can be used to implement variadic functions. [0]

  The last parameter in the parameter list may be a .param array of
  type .b8 with no size specified. It is used to pass an arbitrary
  number of parameters to the function packed into a single array
  object.

  When calling a function with such an unsized last argument, the last
  argument may be omitted from the call instruction if no parameter is
  passed through it.  Accesses to this array parameter must be within
  the bounds of the array.  The result of an access is undefined if no
  array was passed, or if the access was outside the bounds of the
  actual array being passed. [1]

Note that aggregates passed by value as variadic arguments are not
currently supported.

[0] https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#variadic-functions
[1] https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#kernel-and-function-directives-func

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

[libc][bazel] Add missing dependency in string_memory_utils

[ThinLTO] Convert tests to opaque pointers (NFC)

[RISCV] Use vmv.v.i for insertion into lane 0 of undef vector when profitable

If we're initializing lane 0 of an undef vector, we can optionally write to other lanes of the vector. Doing so may require additional work, so we don't want to e.g. always use a splat. However, since we don't have an immediate form of vmv.s.x it's useful to use a vmv.v.i if the work required is expected to be equal in practice.  We restrict this to when LMUL <= 1 to a) prevent doing additional work at higher LMULs, and b) avoid overconstraining the register allocator.

At the moment, the new utility is only used by one case in INSERT_VECTOR_ELT lowering. My expectation is that we will reuse this in a couple other places, but each of those deserve individual review.

This change is inspired by D137530, but is not directly related to it. I vaguely remember we discussed the tradeoffs of using vmv.v.i in another recent review, but couldn't find it.

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

[RISCV][InsertVSETVLI] Reverse traversal order of block in post pass [nfc]

his unblocks a following change to be more sophisticated during post pass rewriting.

Review wise, I basically just want a second set of eyes. This change should be straight forward, but since it took me an embarrassing number of attempts to get make check to pass. Let's make sure I'm not missing yet another cornercase.

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

InstCombine: Fold logic of fp_classes together

Move logical operators on pairs of llvm.is.fpclass on the same value
into the test mask of a single is_fpclass.

or (class x, mask0), (class x, mask1) -> class x, (mask0 | mask1)
and (class x, mask0), (class x, mask1) -> class x, (mask0 & mask1)
xor (class x, mask0), (class x, mask1) -> class x, (mask0 ^ mask1)

The and/or cases should appear frequently in the builtin math
libraries; haven't seen the xor case but handle it for completeness.

InstCombine: Perform simpler test of APFloat first

[mlir][arith] Add canonicalization patterns for 'mul*i_extended'

- Add a fold for `mulsi_extended(x, 1)`
- Add folds to demote wide integer multiplication to `mul*i_extended` when the result is shifted
   and truncated: `trunci(shrui(mul(*ext(x), *ext(y)), c)) -> mul*i_extended(x, y)`

Reviewed By: Mogball

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

[llvm-stress] Support scalable vectors and out of bounds indices to vector ops

This change does two things.

First, it supports scalable vectors in llvm-stress output.  There's an off-by-default flag -enable-scalable-vectors which generates a scalable vector with 50% probability when a random vector type is selected.  Because of the existing implementation, this tends to skew an entire test towards either scalable or fixed since we most select initial values, not random types.

Second, it selects a random value for the index of an insertelement or extractelement.  As a result, out of bounds indices can not appear for fixed lengh vectors.  Previously, it chose a random constant which was, by construction, in range.

[AMDGPU] Add `.workgroup_processor_mode` to v5 MD

Adds Workgroup Processor Mode (WGP) to the HSA Metadata for Code Object v5/GFX10+.
The field is already present as an asm directive and in the compute program resource register but is also needed in the MD.

Reviewed By: kzhuravl

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

[Linker] Convert some tests to opaque pointers (NFC)

[AMDGPU] Add bf16 storage support

- [Clang] Declare AMDGPU target as supporting BF16 for storage-only purposes on amdgcn
  - Add Sema & CodeGen tests cases.
  - Also add cases that D138651 would have covered as this patch replaces it.
- [AMDGPU] Add BF16 storage-only support
  - Support legalization/dealing with bf16 operations in DAGIsel.
  - bf16 as a type remains illegal and is represented as i16 for storage purposes.

Reviewed By: arsenm

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

Revert "[RISC-V][HWASAN] Add support for HWASAN code instrumentation for RISC-V"

This reverts commit 0eb694bec09df488bb6ab33d0207b6b061718d98.
Temporarily revert as it causes a new warning:
https://reviews.llvm.org/D131575#inline-1351186

Revert "Update tests by update_test_checks.py"

This reverts commit 3a8f4649a0a4b7b9cab93d73c0651a14b0fd1c34.
Broke check-llvm everywhere, see e.g.:
* https://lab.llvm.org/buildbot/#/builders/139/builds/32724
* http://45.33.8.238/linux/94174/step_12.txt
* http://45.33.8.238/macm1/50831/step_11.txt
* http://45.33.8.238/win/71928/step_11.txt

[clang][PPC] Checking Unknown Values Passed to -mcpu

Currently `ppc::getPPCTargetCPU` returns an empty string when it encounters an unknown value passed to `-mcpu`. This causes `clang` to ignore unknown `-mcpu` values silently.

This patch changes the behaviour of `ppc::getPPCTargetCPU` so that it passes the unknown option to the target info, so the target info can actually check if the CPU string is supported, and report an error when encountering unknown/unsupported CPU string.

Reviewed By: jamieschmeiser

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

[CanonicalizeAliases] Convert test to opaque pointers (NFC)

Looks like this transform only has a single test :)

[FunctionImport] Convert tests to opaque pointers (NFC)

[ThinLTOBitcodeWriter] Convert tests to opaque pointers (NFC)

[HIP] support --offload-arch=native

This patch detects system GPU and use them
in --offload-arch if 'native' is specified. If system GPU
cannot be detected clang will fall back to the default GPU arch.

Reviewed by: Artem Belevich

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

[DebugInfo] Convert most tests to opaque pointers (NFC)