Finish renaming getOperandSegmentSizeAttr() from `operand_segment_sizes` to `operandSegmentSizes`

This renaming started with the native ODS support for properties, this is completing it.

A mass automated textual rename seems safe for most codebases.
Drop also the ods prefix to keep the accessors the same as they were before
this change:
 properties.odsOperandSegmentSizes
reverts back to:
 properties.operandSegementSizes

The ODS prefix was creating divergence between all the places and make it harder to
be consistent.

Reviewed By: jpienaar

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

[clang] Run test for concrete target

The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.

(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)

[clang] Set FP options in Sema when instantiating CompoundStmt

When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.

To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.

This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).

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

(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)

clang: Fix x86-no-gather-no-scatter.cpp on macOS after 993bdb047c90e9

On macOS, files are usually below `/Users/...` and clang-cl treats
that as the `/U` flag followed by something instead of as a path.
Put `--` in front of `%s` to make it treat it as a patch, like in
all other tests.

The failure without this change:

    x86-no-gather-no-scatter.cpp:4:14: error: NOGATHER: expected string not found in input
    // NOGATHER: "-target-feature" "+prefer-no-gather"
                 ^
    <stdin>:5:44: note: possible intended match here
    clang: warning: 'x86-no-gather-no-scatter.cpp' treated as the '/U' option [-Wslash-u-filename]
                                               ^

(cherry picked from commit 547ee1c81fceaabcb7064ed525f11f9e94083f56)

[MachineLICM][WinEH] Don't hoist register reloads out of funclets

This fixes https://github.com/llvm/llvm-project/issues/60766

With MSVC style exception-handling (funclets), no registers are
alive when entering the funclet so they must be reloaded from the
stack.  MachineLICM can sometimes hoist such reloads out of the
funclet which is not correct, the register will have been clobbered
when entering the funclet.  This can happen in any loop that
contains a try-catch.

This has been tested on x86_64-pc-window-msvc.  I'm not sure if
funclets work the same on the other windows archs.

Reviewed By: rnk, arsenm

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

(cherry picked from commit 917574d5d8beacbefab4d0e6469dac5b50117832)

[BOLT][Instrumentation] Keep profile open in WatchProcess

When a binary is instrumented with --instrumentation-sleep-time and
instrumentation-wait-forks options and lauched, the profile is
periodically written until all the forks die. The problem is that we
cannot wait for the whole process tree, and we have no way to tell when
it's safe to read the profile. Hovewer, if we keep profile open
throughout the life of the process tree, we can use fuser to determine
when writing is finished.

Reviewed By: rafauler

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

(cherry picked from commit a799298152e3ef08b4919cdaac7a614f7cca9bc6)

[Coroutines] [CoroElide] Don't think exceptional terminator don't leak coro handle unconditionally any more

Close https://github.com/llvm/llvm-project/issues/59723.

The fundamental cause of the above issue is that we assumed the memory
of coroutine frame can be released by stack unwinding automatically
if the allocation of the coroutine frame is elided. But we missed one
point: the stack unwinding has different semantics with the explicit
coroutine_handle<>::destroy(). Since the latter is explicit so it shows
the intention of the user. So we can blame the user to destroy the
coroutine frame incorrectly in case of use-after-free happens. But we
can't do so with stack unwinding.

So after this patch, we won't think the exceptional terminator don't
leak the coroutine handle unconditionally. Instead, we think the
exceptional terminator will leak the coroutine handle too if the
coroutine is leaked somewhere along the search path.

Concretely for C++, we can think the exceptional terminator is not
special any more. Maybe this may cause some performance regressions.
But I've tested the motivating example (std::generator). And on the
other side, the coroutine elision is a middle end opitmization and not
a language feature. So we don't think we should blame such regressions
especially we are correcting the miscompilations.

(cherry picked from commit 7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f)

[CGCall][RISCV] Handle function calls with parameter of RVV tuple type

This was an oversight in D146872, where function calls with tuple type
was not covered. This commit fixes this.

Reviewed By: craig.topper

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

(cherry picked from commit 39a41c8905618fc942100630b4ea37f0cb95e786)

[OpenMP][OMPT] Fix `target enter data` callback ordering & reported device num

This patch fixes: https://github.com/llvm/llvm-project/issues/64738
We observed multiple issues, primarily that the `DeviceId` was reported as -1
in certain scenarios. The reason for this is simply that the device is not
initialized at that point. Hence, we need to move the RAII object creation just
after the `checkDeviceAndCtors`, closer to the actual call we want to observe.

This also solves an odering issue where one `target enter data` callback would
be executed before the `Init` callback.
Additionally, this change will also fix that the callbacks corresponding to
`enter / exit data` and `update` in conjunction with `nowait` would not result
in the emission of an OMPT callback.

Added a testcase to cover initialized device number and `omp target` constructs.

Reviewed By: dhruvachak

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

(cherry picked from commit 57f0bdc8fb1e66d4ed9cfb57f1ef699eefd99646)

[OpenMP][OMPT] Fix reported target pointer for data alloc callback

This patch fixes: https://github.com/llvm/llvm-project/issues/64671
DataOp EMI callbacks would not report the correct target pointer.
This is now alleviated by passing a `void**` into the function which
emits the actual callback, then evaluating that pointer.

Note: Since this is only done after the pointer has been properly
updated, only `endpoint=2` callbacks will show a non-null value.

Reviewed By: dhruvachak, jdoerfert

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

(cherry picked from commit 41f3626f8b300cef24c06d9e8b7cf53029a4330a)

[RISCV] Check type size for lax conversions between RVV builtin types and VectorType::RVVFixedLengthDataVector.

This code was copied from SVE and modified for RVV. For SVE, there
is only one size for builtin types so they didn't need to check
the size. For RVV, due to LMUL there are 7 different sizes of builtin
types so we do need to check the size.

I'm not sure we should have lax vector conversions at all for RVV.
That appears to be contributing to https://github.com/llvm/llvm-project/issues/64404

This patch at least fixes the obvious correctness issue.
This should be backported to LLVM 17.

Reviewed By: jacquesguan

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

(cherry picked from commit 33af2f131db71a18aefc5469129540e2097a537f)

[compiler-rt] Use .globl for FreeBSD/NetBSD interceptor wrappers

On FreeBSD and NetBSD we don't use .weak due to differing semantics.
Currently we end up using no directive, which gives a local symbol,
whereas the closer thing to a weak symbol would be a global one. In
particular, both GNU and LLVM toolchains cannot handle a GOT-indirect
reference to a local symbol at a non-zero offset within a section on
AArch64 (see https://github.com/ARM-software/abi-aa/issues/217), and so
interceptors do not work on FreeBSD/arm64, failing to link with LLD.
Switching to .globl both works around this bug and more closely aligns
such non-weak platforms with weak ones.

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

Reviewed By: MaskRay

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

(cherry picked from commit 7e1afab1b1821550c5f8d0d6a50636236fa02e2c)

Revert "[XCOFF][AIX] Peephole optimization for toc-data."

This reverts commit 5e28d30f1fb10faf2db2f8bf0502e7fd72e6ac2e.

(cherry picked from commit cef56b9318e37e9c47fd356c76c9da522bc8c122)

Revert "[PPC][AIX] Fix toc-data peephole bug and some related cleanup."

This reverts commit b37c7ed0c95c7f24758b1532f04275b4bb65d3c1.

(cherry picked from commit ce658829c9ebd23066f4f0aa5dc686350e5f9ba4)

[InstCombine] Fix select + cast fold with constant expression (PR64669)

The zext constant expression was detected by the fold, but then
handled as a sext. Use ZExtOperator instead of ZExtInst to handle
constant expressions.

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

(cherry picked from commit c15ccfb24afa67d3c3f54e52cc1d1afa564715ed)

[SPARC][IAS] Add support for v9 DONE, RETRY, SAVED, & RESTORED

Add support for DONE, RETRY, SAVED, and RESTORED (v9 Section A.11 & Section A.47).

Those instructions are used for low-level interrupt handling and register window
management by OS kernels.

Reviewed By: barannikov88

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

(cherry picked from commit bf499ec2b96c98633a8b2bc2113b19ffd437f647)

[DAG] replaceStoreOfInsertLoad - don't fold if the inserted element is implicitly truncated

D152276 wasn't handling the case where the inserted element is implicitly truncated into the vector - resulting in a i1 element (implicitly truncated from i8) overwriting 8 bits instead of 1 bit.

This patch is intended to be merged into 17.x so I've just disallowed any vector element vs inserted element type mismatch - technically we could be more elegant and permit truncated stores (as long as the store is still byte sized), but the use cases for that are so limited I'd prefer to play it safe for now.

Candidate patch for #64655 17.x merge

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

(cherry picked from commit ba818c4019c550e1a413e1563a05b241b508defd)

[X86] Add test case for Issue #64655

(cherry picked from commit 2c090e9e67d306578dbeb966a34d9fb85b9f4121)

[RISCV] Support global address as inline asm memory operand of `m`

In D146245, we have supported lowering inline asm `m` with offset
to `register+imm`, but we didn't handle the case that the offset
is the low part of global address.

This patch will emit `%lo(g)` when `g` is a global address.

Fixes #64656

Reviewed By: asb

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

(cherry picked from commit dc60003ec8b2faf595b528a39f64b697a589da06)

[RISCV][NFC] Move tests of inline asm memory constraints to separate file

We will need to check the output of medium code model.

Reviewed By: wangpc

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

(cherry picked from commit a3b11ce78680ef39e4dfbc72085ae3e1814e3cba)

[AArch64] [GlobalISel] Fix clobbered callee saved registers with win64 varargs

This fixes a regression since 1c10d5b175992a9d056a2d763a932e5652386fc1
/ https://reviews.llvm.org/D130903 by applying the same fix from
SelectionDAG from 8cb3667541a94c4fa11b06e19020f753414c1d03 /
https://reviews.llvm.org/D35720.

This could possibly have been detected if the existing testcases
in win64_vararg.ll had been tested with GlobalISel too, but all
the IR snippets there fail to be translated with GlobalISel.

This adds a separate testcase based on real world LLVM IR (instead of
hand-reduced IR), which GlobalISel does translate happily - tested
with both SelectionDAG and GlobalISel.

Before this change, the stack object locations (visible in MIR
with "llc -print-after-all") didn't match with what the prologue
emitted by AArch64FrameLowering actually looked like, which caused
clobbered callee saved registers when function local stack objects
aliased the actual location of the callee saved registers.

This fixes https://github.com/llvm/llvm-project/issues/64740.

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

(cherry picked from commit 955d7615bd7563cc78a5106215daf9e6e47ffb5e)

Remove a release note that should not have snuck in

Remove a merge conflict marker that was missed; NFC

No longer hang on typeof of a function type

We were calling `isFunctionProtoType()` on a `ParsedType` rather than
creating a valid semantic type first and calling the function on that.
The call to `isFunctionProtoType()` would eventually call
`getUnqualifiedDesugaredType()`, which loops indefinitely until we get
a desugared type and a `ParsedType` will never finish desugaring.

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

[BPF] Reset machine register kill mark in BPFMISimplifyPatchable

When LLVM is build with `LLVM_ENABLE_EXPENSIVE_CHECKS=ON` option
the following C code snippet:

    struct t {
      unsigned long a;
    } __attribute__((preserve_access_index));

    void foo(volatile struct t *t, volatile unsigned long *p) {
      *p = t->a;
      *p = t->a;
    }

Causes an assertion:

    $ clang -g -O2 -c --target=bpf -mcpu=v2 t2.c -o /dev/null

    # After BPF PreEmit SimplifyPatchable
    # Machine code for function foo: IsSSA, TracksLiveness
    Function Live Ins: $r1 in %0, $r2 in %1

    bb.0.entry:
      liveins: $r1, $r2
      DBG_VALUE $r1, $noreg, !"t", !DIExpression()
      DBG_VALUE $r2, $noreg, !"p", !DIExpression()
      %1:gpr = COPY $r2
      DBG_VALUE %1:gpr, $noreg, !"p", !DIExpression()
      %0:gpr = COPY $r1
      DBG_VALUE %0:gpr, $noreg, !"t", !DIExpression()
      %2:gpr = LD_imm64 @"llvm.t:0:0$0:0"
      %4:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
      %5:gpr = CORE_LD 344, %0:gpr, @"llvm.t:0:0$0:0"
      STD killed %5:gpr, %1:gpr, 0
      %7:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
      %8:gpr = CORE_LD 344, %0:gpr, @"llvm.t:0:0$0:0"
      STD killed %8:gpr, %1:gpr, 0
      RET

    # End machine code for function foo.

    *** Bad machine code: Using a killed virtual register ***
    - function:    foo
    - basic block: %bb.0 entry (0x6210000e6690)
    - instruction: %7:gpr = ADD_rr %0:gpr(tied-def 0), killed %2:gpr
    - operand 2:   killed %2:gpr

This happens because of the way
BPFMISimplifyPatchable::processDstReg() updates second operand of the
`ADD_rr` instruction. Code before `BPFMISimplifyPatchable`:

    .-> %2:gpr = LD_imm64 @"llvm.t:0:0$0:0"
    |
    |`----------------.
    |   %3:gpr = LDD %2:gpr, 0
    |   %4:gpr = ADD_rr %0:gpr(tied-def 0), killed %3:gpr <--- (1)
    |   %5:gpr = LDD killed %4:gpr, 0       ^^^^^^^^^^^^^
    |   STD killed %5:gpr, %1:gpr, 0        this is updated
     `----------------.
        %6:gpr = LDD %2:gpr, 0
        %7:gpr = ADD_rr %0:gpr(tied-def 0), killed %6:gpr <--- (2)
        %8:gpr = LDD killed %7:gpr, 0       ^^^^^^^^^^^^^
        STD killed %8:gpr, %1:gpr, 0        this is updated

Instructions (1) and (2) would be updated to:

    ADD_rr %0:gpr(tied-def 0), killed %2:gpr

The `killed` mark is inherited from machine operands `killed %3:gpr`
and `killed %6:gpr` which are updated inplace by `processDstReg()`.

This commit updates `processDstReg()` reset kill marks for updated
machine operands to keep liveness information conservatively correct.

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

(cherry picked from commit 27026fe5633b546ed647efd99eccdfc598686535)

[X86]Support options -mno-gather -mno-scatter

Gather instructions could lead to security issues, details please refer to https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html.
This supported options -mno-gather and -mno-scatter, which could avoid generating gather/scatter instructions in backend except using intrinsics or inline asms.

Reviewed By: pengfei

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

[SystemZ] Avoid type legalization on structs

In SystemZTTIImpl::getMemoryOpCost, the call to getNumberOfParts will
run type legalization, which can't handle structs. So before that, we
check for an unknown value type and forward to BaseT, just like many
other targets do in this situation.

https://bugzilla.redhat.com/show_bug.cgi?id=2224885

Reviewed By: uweigand

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

(cherry picked from commit 85e4ee15d32ae0344755d11d4ca90a15a6e005cd)

[Driver][unittest] Unbreak ToolChainTest.cpp compilation with -Werror

D157275 broke some buildbots that run with -Werror:

https://lab.llvm.org/buildbot#builders/36/builds/36604
https://lab.llvm.org/buildbot#builders/57/builds/29201

Avoid this by using an overlong line rather than appeasing `clang-format`.

(cherry picked from commit 18252e6c8e2b1bb9901b5cca9e9a75edfeda2c4e)

[Driver] Select newest GCC installation on Solaris

As described in Issue #53709
<https://github.com/llvm/llvm-project/issues/53709>, since
28d58d8fe2094af6902dee7b4d68ec30a3e9d737
<https://reviews.llvm.org/rG28d58d8fe2094af6902dee7b4d68ec30a3e9d737>
`clang` doesn't find the latest of several parallel GCC installations on
Solaris, but only the first in directory order, which is pretty random.

This patch sorts GCC installations in reverse version order so the latest
is picked.

Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.

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

(cherry picked from commit ae84ad15efd7ef7da95146e900ec72ceadf98058)

Add Requires x86 target to test due to failure in clang-armv8-quick
bot

(cherry picked from commit bb5f64a6fc059fcf81b4b9ffe035f5063956ddd8)

[CodeGen][UBSan] Handle sugared QualTypes correctly in
getUBSanFunctionTypeHash.

getUBSanFunctionTypeHash checks if a Type is a FunctionNoPrototype
by calling isa<FunctionNoProtoType>(). This does not work correctly when
the Type is wrapped in a sugar type such as an AttributedType. This
patch fixes this by using isFunctionNoProtoType() function which removes
sugar and returns the expected result.

The added test is a sanity check that the compiler no longer crashes
during compilation. It also compares the hash with and without the
function attribute for both FunctionNoProtoType and FunctionProtoType.
The hash remains the same for FunctionNoProtoType even with the addition
of an attribute.

rdar://113144087

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

(cherry picked from commit 9afc57dcb2e5cd36ca1ddf0fee3efa958bfd4c2a)

[gcov] Ignore blocks from another file

Constructs such as inline variables, #line, and #include can create
lexical blocks with a different filename.
GCOVProfiling and llvm-cov gcov currently don't handle such cases (see
GCOVLines::writeOut and GCOVFile::readGCNO) and would incorrectly
attribute the line number to the current file.

For now, ignore such blocks. Missing line execution counts is better
than wrong ones.

---

As a workaround that Apple targets don't use -mconstructor-aliases yet,
allow line execution count 4 on the A::A line (1f34e282e8066281eb1447e21e44a2a2e9983e79).

(cherry picked from commit 406e81b79d26dae6838cc69d10a3e22635da09ef)

[libc++][doc] Marks LLVM-17 release notes as final.

Reviewed By: #libc, philnik

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

(cherry picked from commit 71a7192d6927b422c224f5d231300774cb02348a)

LowLevelType: replace a reachable llvm_unreachable with assert

assert is more appropriate here and fixes
`runtime error: execution reached an unreachable program point` in a
-DLLVM_USE_SANITIZER=Undefined build (-fno-sanitize-recover=all causes
llc to exit instead of crash (report_fatal_error)) when testing
MachineVerifier/test_g_assert_[sz]ext.mir.

(cherry picked from commit a7e20dd664bbce6e87b1fdad88d719e497902a42)

[ARM] Fix abs overflow when encoding instructions like strb r1, [r0], #-0

Tested by llvm/test/MC/ARM/basic-thumb2-instructions.s.
Caught by newer -fsanitize=signed-integer-overflow (D156821).

(cherry picked from commit d8900f661a6e451be0ca253df3065254008dd93a)

[llvm-readobj] Fix std::abs overflow after D156821

Tested by llvm/test/tools/llvm-readobj/ELF/relocations.test

(cherry picked from commit 07bb66784c17ef6b98ce38f9cc74d1d92f1aac08)

[RISCV] Fix a UBSAN failure for passing INT64_MIN to std::abs.

clang recently started checking for INT64_MIN being passed to 64-bit std::abs.

Reviewed By: MaskRay

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

(cherry picked from commit 078eb4bd85ddaac530bf2919bb32c6daa6c3e36f)

Reapply "[DebugInfo] Alternate (more efficient) MD5 fix"

D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.

This reverts commit 5956648fc3ba11dd6b0d0f2d1d9b923e7f80f247.
There was a string lifetime issue that is now corrected.

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

(cherry picked from commit 1fcc2bc31bb9352a13445ff4a5cccb0bebb8ea5b)

[CodeGen] Keep track of eagerly emitted globals

An inline virtual function must be emitted, but we need to remember
it and emit the same definition again in the future in case later
LLVM optimizations stripped it from the Module. The added test case
shows the problem; before this patch, it would fail with:
    Symbols not found: [ _ZN1AD0Ev, _ZN1AD1Ev ]

This reapplies commit f8dadefd4a, reverted in commit 0e17372b38, but
disables RTTI in the test to avoid problems on Windows.

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

(cherry picked from commit c861d32d7c2791bdc058d9d9fbaecc1c2f07b8c7)

[CodeGen] Restrict addEmittedDeferredDecl to incremental extensions

Reemission is only needed in incremental mode. With this early return,
we avoid overhead from addEmittedDeferredDecl in non-incremental mode.

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

(cherry picked from commit d43a3d6346961e639e29b8083b262416889e78ec)

[CodeGen] Clean up access to EmittedDeferredDecls, NFCI.

GlobalDecls should only be added to EmittedDeferredDecls if they
need reemission. This is checked in addEmittedDeferredDecl, which
is called via addDeferredDeclToEmit. Extend these checks to also
handle VarDecls (for lambdas, as tested in Interpreter/lambda.cpp)
and remove the direct access of EmittedDeferredDecls in EmitGlobal
that may actually end up duplicating FunctionDecls.

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

(cherry picked from commit b719e410781ce9f3a2b316afea31c156bf99e036)

[CodeGen] Remove Constant arguments from linkage functions, NFCI.

This was unused since commit dd2362a8ba last year.

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

(cherry picked from commit 2f3fe3ed97bcf778d73eda5aae9f166810a4af02)

[clang-repl] Disambiguate global namespace identifiers

A double colon starts an identifier name in the global namespace and
must be tentatively parsed as such.

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

(cherry picked from commit ba475a4a3440a21e5de6a39a16215836f2614f04)

[lldb] Fix performance regression after adding GNUstep ObjC runtime

We added support for the GNUstep ObjC runtime in 0b6264738f3d. In order to check if the target process uses
GNUstep we run an expensive symbol lookup in `CreateInstance()`. This turned out to cause a heavy performance
regression for non-GNUstep inferiors.

This patch puts a cheaper check in front, so that the vast majority of requests should return early. This
should fix the symptom for the moment. The conceptual question remains: Why does `LanguageRuntime::FindPlugin`
invoke `create_callback` for each available runtime unconditionally in every `Process::ModulesDidLoad`?

Reviewed By: jasonmolenda, jingham, bulbazord

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

(cherry picked from commit af2eb838309d88f046d34bca6055f1de6078fa3b)

[clangd] Avoid passing -xobjective-c++-header to the system include extractor

Fixes https://github.com/clangd/clangd/issues/1568

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

(cherry picked from commit bd74186f1a0831b2c596e87ea056419379a223c1)

Revert "[clang] Preliminary fat-lto-object support"

FatLTO support is only half complete, and shouldn't be included in the
17.x release. https://reviews.llvm.org/D152973.

This reverts commit 5784c47806cf276e8fcc1311201f437cb8169261.
This reverts commit 610fc5cbcc8b68879c562f6458608afe2473ab7f.

[libc++] Fix a few incorrect CMake configuration options

This patch fixes a few CMake options that were set using incorrect
mechanisms.

CMake's man page for the -D <var>=<value> option states: If a command in
the project sets the type to PATH or FILEPATH, then the <value> will be
converted to an absolute path. That's not what we want for most of the
paths we have as configuration options. Otherwise, using -D to set the
configuration option results in an absolute path being used, which
breaks things.

option() denotes a boolean variable, but what was desired was a
string/list variable. Fix this to prevent cmake from changing any
non-empty user provided values to 'ON'.

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

(cherry picked from commit 760261a3daf98882ccbd177e3133fb4a058f47ad)

[libc++] Work around dynamic linking of stringstream::str() on Windows

Also `istringstream::str()` and `ostringstrem::str()`.

https://github.com/llvm/llvm-project/issues/40363 causes `str()`
to be dllimport'ed despite _LIBCPP_HIDE_FROM_ABI.
This is a temporary solution until #40363 is fixed.

Reviewed By: #libc, thakis, philnik

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

(cherry picked from commit 090996f4a1186b1522e1225b6779d74ce9da250c)

AMDGPU: Fix fast f32 exp2

Mirror of the previous log changes, OpenCL conformance doesn't like
interpreting afn as ignore denormal handling but was previously hidden
by flag dropping.

(cherry picked from commit 81b278e613fb3bcdf8053f7a6b5dd2f3881898d2)

AMDGPU: Fix fast f32 log/log10

OpenCL conformance didn't like interpreting afn as ignore the denormal
handling.

https://reviews.llvm.org/D157940
(cherry picked from commit 4b7b4b945856c46b91ade7b6c4264fe8e258367e)

AMDGPU: Fix fast math log2 f32

Apparently afn doesn't allow you to drop the denormal handling
according to OpenCL conformance. This was hidden by losing the flags
during the library linking process. Fast log is still broken and needs
more work.

https://reviews.llvm.org/D157936
(cherry picked from commit e09b3593ba64d004a9d2b3fa41be2ba84f968a88)

[PreISelIntrinsicLowering] Use TLI for correct function

We should query the subtarget of the calling function, not of the
intrinsic.

This probably makes no functional difference (as libcalls are
unlikely to vary across subtargets), but fixes minor compile-time
regressions from unnecessary subtarget instantiations.

Followup to D157567.

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

(cherry picked from commit 66bb7521625826cab6fcc24662c053deee1ef90c)

PreISelIntrinsicLowering: Check RuntimeLibcalls instead of TLI for memory functions

We need a better mechanism for expressing which calls you are allowed
to emit and which calls are recognized. This should be applied to the
17 branch.

(cherry picked from commit c8cac156135de8e211b800ea5abe9666803b2875)

[libc++][PSTL] Disable `-Wpass-failed`.

PSTL contains many pragmas that request loop vectorization, which would
produce a warning when the compiler is unable to fulfill the request (if
`-Wpass-failed` is enabled). This is normal and expected in some cases,
and we don't want `-Werror` to turn that into a compilation failure.

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

(cherry picked from commit 1d340250a894b6ec956e2145b2fc7babbf83e61b)

[SelectionDAG] Use TypeSize variant of ComputeValueVTs to compute correct offsets for scalable aggregate types.

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

[NFC][SelectionDAGBuilder] Use getObjectPtrOffset in place of discrete nodes.

Some prep work to make aggregate loads and stores TypeSize aware.

[SVE] Add test to show incorrect code generation for scalable vector struct loads and stores.

Patch also includes a minor fix to AArch64::isLegalAddressingMode
to ensure all scalable types have a suitable bailout.

[AArch64] Fix crash when neither Neon nor SVE are enabled

The subtarget was unconditionally reporting that SVE was to be used to
lower vectors when Neon was unavailable, even when SVE itself was
unavailable. This decision leads other parts of the compiler to crash,
e.g., when querying SVE vector sizes.

Reviewed By: sdesmalen

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

(cherry picked from commit c058eb998aa6fa89d412984d6cbf9e3f826249f3)

[WebAssembly][Objcopy] Write output section headers identically to inputs

Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).

This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.

Reviewed By: jhenderson

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

(cherry picked from commit 1b21067cf247c62c2442daa7ee2d3915249d1ee2)

[RISCV] Stop performFP_TO_INTCombine from folding with ISD::FRINT.

FRINT was added to matchRoundingOp after this function was written.
So FRINT was not tested originally.

For vectors, folding this causes us to create a CSR swap that tries
to write 7 to FRM. This is an illegal value and will cause the CSR
write to fail.

While this might be a legal fold we could do, I'm disabling it for
now so we can backport to LLVM 17 with the least risk.

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

(cherry picked from commit 2df9328fe3a0575fa415964a3c3544b0912b168e)

Reapply [CHR] Fix up phi nodes with unreachable predecessors (PR64594)

Relative to the previous attempt, this also adjusts RegionInfo
verification to allow unreachable predecessors.

-----

If a block in the CHR region has an unreachable predecessor, then
there will be no edge from that predecessor to the newly cloned
block. However, a phi node entry for it will be left behind. Make
sure that these incoming blocks get dropped as well.

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

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

(cherry picked from commit 7e2f1ae7e0ebc7e71ffaa865175aef27fae3b034)

Revert "[Profile] Remove duplicate file locks when enabled continuous mode and online merging."

This reverts commit 985486dca48bffd9e991d9f5ac32e1d109ae000f.

This seems to cause malformed profdata: crbug.com/1469456

(cherry picked from commit 4b08be77c98a4c15b8b3d634fab4ffc24bf4ef38)

Fix truncated __OPENMP_NVPTX__ preprocessor condition

I don't have a test case for this but noticed this warning when including system headers with `-I` rather than `-isystem`.

```
In file included from <built-in>:1:
In file included from /nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_runtime_wrapper.h:157:
/nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_math.h:39:25: warning: extra tokens at end of #ifdef directive [-Wextra-tokens]
                        ^
```

Reviewed By: tra

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

(cherry picked from commit c49142e4f5c8645a4d741d233f0cb55ef1ef87a2)

flang: Fix module-debug-file-loc-linux.f90 in standalone

In a standalone build, there is no guarantee that flang code would be
saved in a directory named flang. Check only the path under flang's root
directory.

Reviewed By: #flang, kiranchandramohan

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

(cherry picked from commit 94f377d880376fa6d5653430cad2777e51759d48)

[clang] Skip stores in init for fields that are empty structs

An empty struct is handled as a struct with a dummy i8, on all targets.

Most targets treat an empty struct return value as essentially
void - but some don't. (Currently, at least x86_64-windows-* and
powerpc64le-* don't treat it as void.)

When intializing a struct with such a no_unique_address member,
make sure we don't write the dummy i8 into the struct where there's
no space allocated for it.

Previously it would clobber the actual valid data of the struct.

Fixes https://github.com/llvm/llvm-project/issues/64253, and
possibly https://github.com/llvm/llvm-project/issues/64077
and https://github.com/llvm/llvm-project/issues/64427 as well.

We should omit the store for any empty record (not only ones
declared with no_unique_address); we can have a situation where a
class doesn't have the no_unique_address attribute, but is embedded
in an outer struct with the no_unique_address attribute - like this:

    struct S {};
    S f();
    struct S2 : public S { S2();};
    S2::S2() : S(f()) {}
    struct S3 { int x; [[no_unique_address]] S2 y; S3(); };
    S3::S3() : x(1), y() {}

Here, the problematic store (which this patch omits) is in
the constructor of S2. In the case of S3, S2 has no valid storage
and aliases x - thus the constructor of S2 should omit the dummy
store.

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

(cherry picked from commit d60c3d08e78dfbb4b180776b83e910d810e1f36a)

[RISCV] Add bounds check before use on returned iterator.

Check iterator validity before use; fixes a crash seen in the RISC-V
Zcmp Push/Pop optimization pass when compiling an internal benchmark.

Reviewed By: asb, wangpc

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

(cherry picked from commit 53e89f5e3f2cefa432f7262343654c2a582dcbe1)

[Driver] Default riscv*- triples to -fdebug-default-version=4

This adds a RISC-V special case to ToolChain::GetDefaultDwarfVersion,
affecting Linux/Haiku/RISCVToolChain.

DWARF v5 .debug_loclists/.debug_rnglists's
DW_LLE_offset_pair/DW_RLE_offset_pair entry kinds utilitize `.uleb128 A-B`
directives where A and B reference local labels in code sections.
When A and B are separated by a RISC-V linker-relaxable instruction,
A-B is incorrectly folded without a relocation, causing incorrect debug
information.

```
void ext(void);
int foo(int x) {ext(); return 0;}
// DW_AT_location [DW_FORM_loclistx] of a DW_TAG_formal_parameter references a DW_LLE_offset_pair that can be incorrect after linker relaxation.

int ext(void);
void foo() { {
  int ret = ext();
  if (__builtin_expect(ret, 0))
    ext();
} }
// DW_AT_ranges [DW_FORM_rnglistx] of a DW_TAG_lexical_block references a DW_RLE_offset_pair that can be incorrect after linker relaxation.
```

D157657 will implement R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128
relocations, fixing the issue, but the relocation is only supported by
bleeding-edge binutils 2.41 and not by lld/ELF yet.

The goal is to make the emitted DWARF correct after linking.
Many users don't care about the default DWARF version, but a linker
error will be unacceptable. Let's just downgrade the default DWARF
version, before binutils>=2.41 is more widely available.

An alternative compatibility option is to add a toggle to DwarfDebug.cpp,
but that doesn't seem like a good idea.

Reviewed By: asb, kito-cheng

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

(cherry picked from commit bbc0f99f3bc96f1db16f649fc21dd18e5b0918f6)
(with a release note)

[clang-tidy] Fix crash when diagnostic is emit with invalid location

Fix crash when diagnostic is emit with invalid location,
but with attached valid ranges. Diagnostic can contain
invalid location, but SourceManager attached to it still
can be valid, use it in such case or fallback to known
SourceManager.

Fixes: #64602

Reviewed By: aaron.ballman

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

(cherry picked from commit efd44f80a5a8194b9fe26ff3244ce702cd8dab73)

Revert "[Sema] Fix handling of functions that hide classes"

This reverts commit d031ff38779bd688c514136dbdcce3169ee82b6e.
See https://reviews.llvm.org/D154503#4576393 for a reproducer and
details.

(cherry picked from commit 7d259b36d2e8148d13087844e6494ad3a5c63edf)

[flang] Add missing dependency on tablegen files

This issue was raised on https://github.com/llvm/llvm-project/issues/64268.

`flang/lib/Optimizer/Transforms/SimplifyIntrinsics.cpp` includes
`flang/Optimizer/HLFIR/HLFIRDialect.h` and might fails if the HLFIR related
tablegen files have not been generated.

Reviewed By: vzakhari

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

(cherry picked from commit 103907bc5fcf656b1551e191af8176cd7bfb91da)

[SDAG] Don't transfer !range metadata without !noundef to SDAG (PR64589)

D141386 changed the semantics of !range metadata to return poison
on violation. If !range is combined with !noundef, violation is
immediate UB instead, matching the old semantics.

In theory, these IR semantics should also carry over into SDAG.
In practice, DAGCombine has at least one key transform that is
invalid in the presence of poison, namely the conversion of logical
and/or to bitwise and/or (https://github.com/llvm/llvm-project/blob/c7b537bf0923df05254f9fa4722b298eb8f4790d/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L11252).
Ideally, we would fix this transform, but this will require
substantial work to avoid codegen regressions.

In the meantime, avoid transferring !range metadata without
!noundef, effectively restoring the old !range metadata semantics
on the SDAG layer.

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

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

(cherry picked from commit 9deee6bffa9c331f46c68e5dd4cb4abf93dc0716)

[X86] Add test for PR64589 (NFC)

(cherry picked from commit 59d558a37850611f9b63a5c1a8bfe87a9606c81e)

[SelectionDAG] Fix problematic call to EVT::changeVectorElementType().

The function changeVectorElementType assumes MVT input types will
result in MVT output types.  There's no gurantee this is possible
during early code generation and so this patch converts an instance
used during initial DAG construction to instead explicitly create a
new EVT.

NOTE: I could have added more MVTs, but that seemed unscalable as
you can either have MVTs with 100% element count coverage or 100%
bitwidth coverage, but not both.

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

(cherry picked from commit b7e6e568b4f28124060b868e433f36af18c510db)

Revert "[AggressiveInstCombine] Fold strcmp for short string literals"

This reverts commit 8981520b19f2d2fe3d2bc80cf26318ee6b5b7473.

[CMake] Set version suffix to `rc` during the RC phase

See discussion in https://github.com/llvm/llvm-project/issues/64225

[clang-tidy] fix None tmpdir when exporting fixes in run-clang-tidy

Differential https://reviews.llvm.org/D145477 removed the check for `(yaml and args.export_fixes)` in line 303 to skip looking for the `clang-apply-replacements` binary. However, the `tmpdir` variable was set in this true branch when exporting fixes and therefore is `None` when invoking run-clang-tidy with `run-clang-tidy -p . -export-fixes fixes.yaml`.

Reviewed By: PiotrZSL

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

(cherry picked from commit c3da99275a520b73235d975017502876e07e3e8e)

[BPF] Don't crash on missing line info

When compiling Rust code we may end up with calls to functions provided
by other code units. Presently this code crashes on a null pointer
dereference - this patch avoids that crash and adds a test.

Reviewed By: ast

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

(cherry picked from commit 055893beacb34441467eb997a270a620c57c138f)

[AMDGPU] Do not release VGPRs at -O0

This was an oversight when the GFX11 early release VGPRs optimization
was reimplemented in D153279.

Sending the DEALLOC_VGPRS message is a performance optimization so there
is no need to do it at -O0. In addition it makes some kinds of post
mortem debugging hard or impossible, since VGPR values are no longer
available to inspect at the s_endpgm instruction.

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

(cherry picked from commit 3091bdb86d55e404866823b64d21fd87c247d893)

[RISCV] Fix wrong type prototype of RVVSlideOneBuiltinSet

We need unsigned integer here.

Fixes #64534

Reviewed By: eopXD

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

(cherry picked from commit 5a3753f35632f8fd7920c5c99b1237113b5c435e)

[Driver] Allow for sparcv8plus subdir with Solaris/SPARC GCC

Since GCC 11, the bundled Solaris/SPARC GCC uses the `sparcv8plus`
subdirectory for 32-bit objects, just like upstream GCC.  Before that, it
used `32` instead from a local patch.

Since `clang` doesn't know about that `sparcv8plus` subdirectory, it
wouldn't properly use GCC 11+ installations.

The new `solaris-sparc-gcc-search.test` testcase wasn't run initially (like
the existing `crash-report-null.test`) because the `.test` suffix wasn't
handled.

Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.

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

(cherry picked from commit 43dfe0f08ecaf50f986512d0548bd3ac84d1813b)

[Clang] Backport static_assert messages fixes

* 4d494e7: Handle static_assert messages with an expression started by a literal
* 49e0495 Produce a warning instead of an error in unevaluated strings before C++26

Emiting an error on unexpected encoding prefix - which was allowed before C++26 -
caused build errors for a few users.
This downgrade the error to a warning on older language modes and C

[lld][LoongArch] Support the R_LARCH_PCREL20_S2 relocation type

`R_LARCH_PCREL20_S2` is a new added relocation type in LoongArch ELF
psABI v2.10 [1] which is not corvered by D138135 except `R_LARCH_64_PCREL`.

A motivation to support `R_LARCH_PCREL20_S2` in lld is to build the
runtime of .NET core (a.k.a `CoreCLR`) in which strict PC-relative
semantics need to be guaranteed [2]. The normal `pcalau12i + addi.d`
approach doesn't work because the code will be copied to other places
with different "page" and offsets. To achieve this, we can use `pcaddi`
with explicit `R_LARCH_PCREL20_S2` reloc to address +-2MB PC-relative
range with 4-bytes aligned.

[1]: https://github.com/loongson/la-abi-specs/releases/tag/v2.10
[2]: https://github.com/dotnet/runtime/blob/release/7.0/src/coreclr/vm/loongarch64/asmhelpers.S#L307

Reviewed By: xen0n, MaskRay

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

(cherry picked from commit 8a31f7ddb8436fa2a8ad754eb51618139cf63415)

[AArch64][PtrAuth] Fix unwind state for tail calls

When generating unwind tables for code which uses return-address
signing, we need to toggle the RA_SIGN_STATE DWARF register around any
tail-calls, because these require the return address to be authenticated
before the call, and could throw an exception. This is done using the
.cfi_negate_ra_state directive before the call, and .cfi_restore_state
at the start of the next basic block.

However, since D153098, the .cfi_restore_state isn't being inserted,
because the CFIFixup pass isn't being run. This re-enables that pass
when return-adress signing is enabled.

Reviewed By: ikudrin, MaskRay

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

(cherry picked from commit f2e7285b03fbfc263c8a2eaa2b5e2e1cfafc6abd)

[AArch64] Refactor checks in sign-return-address.ll test

Using implicit CHECK prefix in one FileCheck invocation and explicit
CHECK-V83A in the other one seems to misguide to use CHECK: lines as
a common matching prefix at various places. Also note that

; CHECK, CHECK-V83A: ...

line only matches the "CHECK-V83A" prefix.

This commit explicitly splits the checks into common ones (CHECK) and
invocation-specific ones (COMPAT and V83A) and updates the assertions
with the update_llc_test_checks.py script.

Reviewed By: efriedma, MaskRay

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

(cherry picked from commit 4210204f521be3caa0e60bd596af3444cbd44d04)

[PPC][AIX] Fix toc-data peephole bug and some related cleanup.

Set the ReplaceFlags variable to false, since there is code meant only
for the ADDItocHi/ADDItocL nodes. This has the side effect of disabling
the peephole when the load/store instruction has a non-zero offset.
This patch also fixes retrieving the `ImmOpnd` node from the AIX small
code model pseduos and does the same for the register operand node.
This allows cleaning up the later calls to replaceOperands.
Finally move calculating the MaxOffset into the code guarded by
ReplaceFlags as it is only used there and the comment is specific to the ELF
ABI.

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

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

(cherry picked from commit b37c7ed0c95c7f24758b1532f04275b4bb65d3c1)

[RISCV] Add back handling of X > -1 to ISD::SETCC lowering.

There are cases where the -1 doesn't become visible until lowering
so the folding doesn't have a chance to run.

I think in these cases there is a missed DAGCombine for truncate (undef),
which I may fix separately, but RISC-V backend should protect itself.

Fixes #64503.

Reviewed By: asb

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

(cherry picked from commit 7cc615413fd7c93421052a193bc3e114465747c9)

BOLT Release Notes

[llvm-rc] Resolve the executable path if not present in Argv[0]

The llvm-rc tool tries to locate a suitable Clang executable to
use for preprocessing. For this purpose, it first checks within
the same directory as the llvm-rc tool, checking with a couple
different names, followed by checking all of $PATH for another
couple names.

On Windows, the InitLLVM() function always sets up Argv[0] with the
full path to the executable, while on Unix, Argv[0] is kept as is.

Therefore, call getMainExecutable to try to resolve the directory of
the executable before looking for colocated Clang executables.

This makes 282744a9ce18120dc0a6eceb02693b36980d9498 actually have
the desired effect.

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

(cherry picked from commit 8c6a0c8bf50bca6c3a0c4de1b84f21466ee31655)

[libc++][doc] Updates format related release notes.

As suggested by @ldionne.

Reviewed By: ldionne, #libc, avogelsgesang

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

(cherry picked from commit cf83cfb3a569632c0049f11d0f56b851aaf21393)

[MLIR] Make the `ConversionTarget` const ref in the DialectConversion (NFC)

It isn't mutated during the conversion already, communicate this through the API.

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

Clarify the invariant of the MLIR pass pipeline around `Pass::initialize()`

This method should not load new dialect or affect the context itself.

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

[mlir][VectorOps] Fix folding of vector.extract from stretch vector.broadcast

Previously, foldExtractFromBroadcast() would incorrectly fold:

  func.func @extract_from_stretch_broadcast(%src: vector<3x1x2xf32>) -> f32 {
    %0 = vector.broadcast %src : vector<3x1x2xf32> to vector<3x4x2xf32>
    %1 = vector.extract %0[0, 2, 0] : vector<3x4x2xf32>
    return %1: f32
  }

to:

  func.func @extract_from_stretch_broadcast(%src: vector<3x1x2xf32>) -> f32 {
    %0 = vector.extract %src[0, 2, 0] : vector<3x1x2xf32>
    return %0: f32
  }

This was due to the wrong offset being used when zeroing the "dim-1"
broadcasted dims. It should use the difference in rank across the
broadcast as the starting offset, as the ranks after that are the ones
that could have been stretched.

Reviewed By: awarzynski, dcaballe

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

[mlir] Store segment sizes in std::array

This revision uses std::array instead of normal c arrays to store the
operand and result segment sizes. This is a follow up to
https://reviews.llvm.org/D155919, which converted the operand and result
segment sizes to properties. Its use of c arrays triggered warnings in
downstream projects due to the direct comparison of c arrays. This
revision fixes the warnings using std::arrays that implement a
proper comparison operator, which compares the array elements rather
that the array pointers.

Note: it seems the comparison operator is effectively dead code for now.
It still seems useful to fix the warning and ensure the comparison works
as expected assume someone starts using it at some point in time.

Reviewed By: mehdi_amini

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

[MLIR][Bytecode] Add missing field initializer in constructor initializer list

Leaving this field unitialized could led to crashes when it'll diverge from the
IRNumbering phase.

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

[mlir] Reduce warnings for bad assertion in generated code

When the operation has no attributes, the generated assertion is
always false and triggers lots of warnings in the build.

```
warning: comparison of unsigned expression < 0 is always false
```

Just return a StringAttr when there is no attribute.

Reviewed By: mehdi_amini

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

[mlir][llvm] Fix export of 64-bit integer function attributes

The `allocsize` attribute is weird because it packs two 32-bit values
into a 64-bit value. It also turns out that the passthrough attribute
exporter was using `int`, which is incorrectly handling 64-bit integers.

Reviewed By: rriddle

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

[mlir][gpu] NFC - Fail gracefully when type conversion fails instead of crashing

[mlir] Fix arith verifier for tensor with encoding

The verifier for some arith ops were not considering that ranked
tensor types can have encodings.

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

[mlir][LLVMIR] Fix identified structs with same name

Different identified struct types may have the same name ("").
Previously, these were deduplicated based on their name, which caused
an assertion failure when nesting identified structs:

    %0 = type { %1 }
    %1 = type { i8 }
    declare void @fn(%0)

Reviewed By: gysit

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

[mlir-lsp] Guard writing output to JSONTransport with mutex

This allows for users of the lsp transport libraries to process replies
in parallel, without overlapping/clobbering the output.

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