If the masking AND has multiple users we fail to remove it.

The current behaviour of `useDefaultTypePrinterParser` and `useDefaultAttributePrinterParser` is that they are set by default, but the dialect generator only generates the declarations for the parsing and printing hooks if it sees dialect types and attributes. Same goes for the definitions generated by the AttrOrTypeDef generator.

This can lead to confusing and undesirable behaviour if the dialect generator doesn't see the definitions of the attributes and types, for example, if they are sensibly separated into different files: `Dialect.td`, `Ops.td`, `Attributes.td`, and `Types.td`.

Now, these bits are unset by default. Setting them will always result in the dialect generator emitting the declarations for the parsing hooks. And if the AttrOrTypeDef generator sees it set, it will generate the default implementations.

Reviewed By: rriddle, stellaraccident

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

Needed to link llvm-debuginfod-find after eafa0530.

should not receive as exceptions (some will get converted to BSD
signals instead).  This is really the only stable way to ensure that
a Mach exception gets converted to it's equivalent BSD signal.  For
programs that rely on BSD signal handlers, this has to happen or you
can't even get the program to invoke the signal handler when under
the debugger.

This builds on a previous solution to this problem which required you
start debugserver with the -U flag.  This was not very discoverable
and required lldb be the one to launch debugserver, which is not always
the case.

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

This partially reverts commit 9cddfe30,
specifically passthrough for CMAKE_OSX_* since this can lead to build
passing through internal variables when it's not intended.

This allows llvm-debuginfod-find to locate binaries in local build ID
directories configured via --debug-file-directory, the same flag used
for this purpose by llvm-symbolizer. This provides a consistent lookup
semantics between the two tools when configured the same way, in
particular when debug binaries may be located either locally or
remotely.

Reviewed By: phosek

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

New diagnostics were added for unreachable generic selection expression
associations in ca75ac5f, but it did
not account for a difference in behavior between C and C++ regarding
lvalue to rvalue conversions. So we would issue diagnostics about a
selection being unreachable and then reach it. This corrects the
diagnostic behavior in that case.

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

getNewMemBuffer has called memset.

Reviewed By: alexander-shaposhnikov

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

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

Reviewed By: LegalizeAdulthood

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

This function tries to match (a >> 8) | (a << 8) as (bswap a) >> 16.

If the SRL isn't masked and the high bits aren't demanded, we still
need to ensure that bits 23:16 are zero. After the right shift they
will be in bits 15:8 which is where the important bits from the SHL
end up. It's only a bswap if the OR on bits 15:8 only takes the bits
from the SHL.

Fixes PR55484.

Reviewed By: RKSimon

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

Program may set the RA_SIGN_STATE pseudo register by expressions.
Libunwind expected only the DW_CFA_AARCH64_negate_ra_state could change the value
of the register which leads to runtime errors on PAC enabled systems.
In the recent version of the aadwarf64[1] a limitation is added[2] to forbid the mixing the
DW_CFA_AARCH64_negate_ra_state with other DWARF Register Rule Instructions.

[1] https://github.com/ARM-software/abi-aa/releases/tag/2022Q1
[2] https://github.com/ARM-software/abi-aa/pull/129

Reviewed By: #libunwind, MaskRay

Differential Revision: https://reviews.llvm.org/D123692
Reland: test moved because it depends on exceptions.

Add a test.

Reviewed By: aartbik

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

This does 2 things:
* Moves it after the short options. Which makes sense given it's
  a niche, default off option.
  (if 2 files for one option seems a bit much, I am going to reuse
  them for "memory find" later)
* Fixes the use of repeated commands. For example:
    memory read buf --show-tags
    <shows tags>
    memory read
    <shows tags>

Added tests for the repetition and updated existing help tests.

Reviewed By: omjavaid

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

This reverts commit ca875539.

As theorized, it does look like opnew is not getting inferred inaccessiblemmemonly.

- Use `Overloaded` rather than `Mangled`.
- Use `Prototype` or `Desc` rather than `Seq`, it's not just a string sequence.
  - `Prototype` for those PrototypeDescriptor will used to evaluate as argument type.
  - `Desc` for those PrototypeDescriptor will used to evaluate as part of function name.

Reviewed By: khchen

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

The Arm test had a incorrect check line with the wrong offset. From the
look of the code it should be -400*4 = 0xFFFFF9C0 = 4294965696

Currently the library ignores requested wait policy in the presence
of tasking. Threads always actively spin. The patch fixes this problem
making the wait policy passive if this explicitly requested by user.

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

Since we already have a dedicated file for testing the /Zc: flags,
let's be consistent about putting /Zc: tests there.

No behavior change.

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

This reverts commit 9b1e0073.

Nikic reported in commit thread that I had forgotten history here, and that a) we'd tried this before, and b) had to revert due to an unexpected codegen impact.  Current measurements confirm the same issue still exists.

Make sure to also handle extended value types to avoid crashing.

Resulting integers greater than 64 bits are not optimized (i128 is not a
legal type), and vectorizing seems to result in libcalls instead of just
scalarization.

Other extended vector types like <10 x float> are however now handled and
should result in vectorized conversions.

Reviewed By: Ulrich Weigand

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

Evaluation odering in function call arguments is implementation-dependent.
In fact, gcc evaluates bottom-top and clang does top-bottom.

Fixes #55283 partially.

Part of https://reviews.llvm.org/D125627

Opaque pointers cannot be polymorphic on the pointed type given their
lack thereof. However they are currently accepted by tablegen but the
intrinsic signature verifier trips when verifying any further
polymorphic type because the opaque pointer codepath for pointers will
not push the pointed type in ArgTys.

This commit adds an assert to easily catch such cases instead of having
the generic signature match failure.

Reviewed By: #opaque-pointers, nikic

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

Currently several buildbots give unsymbolized traces on crash.
I suspect these are configuring the symbolizer in this way and regressed in
D122251 or thereabouts.

Trying this coupled with a reland of patch that failed on a couple of bots with
no useful stacktrace...

This reverts commit 6aabf60f.

We could do better by inserting a bitcast from scalar int
to vector int or using an insertelement (the alternate test
does not crash because there's an independent fold like that).

But this doesn't seem like a likely pattern, so just bail out
for now.

Fixes issue #55516.

Previously if you read a code/data mask before there was a valid thread
you would get the top byte mask. This meant the value was "valid" as in,
don't read it again.

When using a corefile we ask for the data mask very early on and this
meant that later once you did have a thread it wouldn't read the
register to get the rest of the mask.

This fixes that and adds a corefile test generated from the same program
as in my previous change on this theme.

Depends on D118794

Reviewed By: omjavaid

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

InstCombine is not required to do anything sensible if it receives
invalid IR.

These tests seem to be testing self-referential instructions that
may occur in unreachable code -- but InstCombine actually goes out
of the way to remove such instructions ahead of time so it doesn't
need to deal with them.

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

Reviewed By: ldionne, #libc

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