Reviewed By: lntue

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

Reviewed By: lntue

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

We created a SIGN_EXTEND_INREG when we created the ABSW so the
input should have 33 sign bits, but check it to be safe.

The andi, zext.h and slli+srli shift pairs at the end of the generated
output are unnecessary if the input is sign extended.

Precommit sort and format of methods from D140331.

Link: https://reviews.llvm.org/D140331
Link: https://github.com/llvm/llvm-project/issues/59538

New named metadata "dx.entryPoints" is added to save all entries.

Each entry is in format of
!{ptr to function, name, signature, resource table, extra}

For compute shader, the extra will save num of threads in format of {i32 x, i32 y, i32 z}

For library profile, an empty entry will be added to save the resource table for the library.

Signature and resource table metadata is not generated yet.

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

Clear active contexts and running passes whenever finalizing crash
report message. Ran into segfault where a failure in dynamic pipeline
resulted in querying a pass whose passmanager had already been destroyed
come time for creating summary of running passes. Conservatively clear
both running states as I don't think there is recovery intended from
pass pipeline failure.

Additionally restrict to one reproducer per report - else we end up
clobbering the same reproducer file over and over again. So instead of
ending with last reproducer we now end up with the first reproducer
while not creating and clobbering reproducers over and over again.

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

I brought the overview document up to date and added information for
most compilation phases to dump out the reeults of the phase.

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

The `stdatomic.h` header cannot be included under MSVC when in C++ mode
as the toolsets prior to 17.5.0 Preview 2 do not support the C11
atomics.  However, some toolsets prior to the aforementioned version
support the atomics under the C++ mode.  In these versions the MSVC
toolset protects against the contamination by entirely eliding the
declarations, resulting in build failures in some cases.  Unfortunately,
e0c3142a accidentally regressed the C
case when fixing the C++ support.

Unfortunately, we cannot test this reliably as we need to inject a
header after the resource path as a system header path, which we do not
have a reliable means of doing.

Fixes: #59640

The 'aes' target guard includes both FEAT_AES and FEAT_PMULL currently.

In this way, cpp code that uses these intrinsics without specifying the required extension gets better hint.
- Before, compile crashes with LLVM ISel internal message (see issue [[ https://github.com/llvm/llvm-project/issues/59599 | 59599 ]]).
- After, clang hints that target 'aes' is required in the command.

Reviewed By: dmgreen

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

Similar for sub, or, and xor. These are all operations that have 0
as a neutral value. This is based on a similar tranform in InstCombine.

This allows us to remove some XVentanaCondOps patterns and
some code from DAGCombine for RISCVISD::SELECT_CC.

Reviewed By: asb

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

[Clang] Modify sanity check assert in AggExprEmitter::VisitInitListExpr to cover anonymous struct in a union GNU extension

AggExprEmitter::VisitInitListExpr sanity checks that an empty union is really
empty and not a semantic analysis failure. The assert is missing that we allow
anonymous structs as a GNU extension. I have updated the assert to take that into account.

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

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

Reviewed By: #bolt, ayermolo

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

These are test for select (and (x , 0x1) == 0), (z ^ y), y ) and select (and (x , 0x1) == 0), (z | y), y )

These can be made branchless by using ((x-1) & z ) ^ y.

Rename the `__tuple` directory in libc++ headers to `__tuple_dir`
to avoid file collision when installing.  Historically, `__tuple` has
been a file and it has been replaced by a directory
in 2d52c6bf.  Replacing a regular file
with a directory (or more importantly, the other way around when
downgrading) is not universally supported.  Since this is an internal
header, its actual name should not matter, so just rename it to avoid
problems.

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

For cases where we can automatically construct the Attribute allow for more
user-friendly input. This is consistent with C++ builder generation as well
choice of which single builder to generate here (most
specialized/user-friendly).

Registration of attribute builders from more pythonic input is all Python side.
The downside is that
  * extra checking to see if user provided a custom builder in op builders,
  * the ODS attribute name is load bearing
upside is that
  * easily change these/register dialect specific ones in downstream projects,
  * adding support/changing to different convenience builders are all along with
    the rest of the convenience functions in Python (and no additional changes
    to tablegen file or recompilation needed);

Allow for both building with Attributes as well as raw inputs. This change
should therefore be backwards compatible as well as allow for avoiding
recreating Attribute where already available.

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

The loops generated under IsContiguous check for copy-in/copy-out
result in LLVM backend spending too much time optimizing them.
At the same time, the copy loops do not provide any optimization
opportunities with the surrounding code (since they are executed
under runtime IsContiguous check), so the copy code may be optimized
on its own and this can be done in runtime.

I thought I could implement and use new APIs for packing/unpacking
non-contiguous data (interfaces added in D136378), but then I found
that Assign() is already doing what is needed. If performance
becomes an issue for these loops, we can optimize code in Assign()
rather than creating new APIs.

Thus, this change makes use of Assign() for copy-in/copy-out
of boxed objects, and this is done only if the objects
are non-contiguous during execution. Copies for non-boxed
objects (e.g. for passing as VALUE dummy argument) are still
done inline, because they can potentially be optimized with
surro...

Encoding was accidentally left out here even though it forms part of the type.
This is small tightening step and I'll look at follow on to tighten more.

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

Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>

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

These used a regex that didn't guard against backslashes, so
getting "lucky" with a temp dir name could make them fail.

This reverts commit a6d6d40d.

Reason: Broke the ASan/MSan bots. More information in phabricator:
https://reviews.llvm.org/D140406

Generated via `nina generate-cxx-abilist`.

Reviewed By: Mordante, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D140431

The function year_month_weekday::sys_days should work properly with a
weekday index of 0 per [time.cal.ymwd.members]/20. This adds a test for
this case.

Reviewed By: #libc, ldionne

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

In c6d7e80e this test was converted from hand written to autogenerated,
during which the relevant metadata CHECKs were dropped. In D85172 the intention
of the CHECK lines is to ensure that for two dbg.declares with different
inlining scopes, attached to the same alloca, two sets of dbg.values will be
generated with the same set of inlining scopes. Without metadata checks, a
single DILocation can match the !dbg CHECKs.

Implements:
- LWG3792 __cpp_lib_constexpr_algorithms should also be defined in <utility>

Depends on D140407

Reviewed By: #libc, philnik, ldionne

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

Directly marked entries with Nothing to do where applicable.

Reviewed By: #libc, ldionne

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

Previously, we would only attempt to perform a parenthesized aggregate
initialization if constructor initialization failed for only the default
constructor, default copy constructor, and default move constructor. The
original intent of this logic was to reject initializing objects that
have failed resolving a user-defined constructor. However, this check is
redundant because we check for isAggregate() before attempting to
perform a parenthesized aggregate initialization, and classes that have
user-defined or user-declared constructors are not aggregates.
Furthermore, this check is too restrictive - the following valid
examples fail:
* Aggregate class with user-defined destructor - fails because default
  move constructors are not generated for classes with user-defined
  destructors
  (https://github.com/llvm/llvm-project/issues/54040#issuecomment-1356926048)
* Concept-guarded conversion operator on an aggregate's member:
  (https://github.com/llvm/llvm-project/issues/54040#issuecomment-1356931745)

The solution therefore is to remove this logic; existing tests still
pass, and the previously failing examples now compile.

Reviewed By: ilya-biryukov

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

This mirrors a similar shufflevector transformation so the same
effect is obtained for scalable vectors. The transformation is
only performed when it can be proven the number of resulting
reversals is not increased. By bubbling the reversals from operand
to result this should typically be the case and ideally leads to
back-back shuffles that can be elimitated entirely.

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

This mirrors a similar shufflevector transformation so the same
effect is obtained for scalable vectors. The transformation is
only performed when it can be proven the number of resulting
reversals is not increased. By bubbling the reversals from operand
to result this should typically be the case and ideally leads to
back-back shuffles that can be elimitated entirely.

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

This mirrors a similar shufflevector transformation so the same
effect is obtained for scalable vectors. The transformation is
only performed when it can be proven the number of resulting
reversals is not increased. By bubbling the reversals from operand
to result this should typically be the case and ideally leads to
back-back shuffles that can be elimitated entirely.

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

This reverts e4b126cc and
e57ab8fe.

This previously depended on where the target happened to construct (or
not) the MachineFunctionInfo during the initial MIR construction. Now
that the MachineFunctionInfo is consistently constructed at
MachineFunction construction time, this should always work.

This fixes what I consider to be an API flaw I've tripped over
multiple times. The point this is constructed isn't well defined, so
depending on where this is first called, you can conclude different
information based on the MachineFunction. For example, the AMDGPU
implementation inspected the MachineFrameInfo on construction for the
stack objects and if the frame has calls. This kind of worked in
SelectionDAG which visited all allocas up front, but broke in
GlobalISel which hasn't visited any of the IR when arguments are
lowered.

I've run into similar problems before with the MIR parser and trying
to make use of other MachineFunction fields, so I think it's best to
just categorically disallow dependency on the MachineFunction state in
the constructor and to always construct this at the same time as the
MachineFunction itself.

A missing feature I still could use is a way to access an custom
analysis pass on the IR here.

Generate brh, brw and brd instructions for byte-swap operations
on P10 and generating a single instruction for a 32-bit swap followed
by a 16-bit right shift.

Reviewed By: stefanp

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

This adds a simple fold of TRUNCATE(AArch64ISD::DUP) -> AArch64ISD::DUP,
which can help generate more optimal UMULL sequences, and seems useful
in general.

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

In the X == C ? f(X) : Y -> X == C ? f(C) : Y fold, perform the
replacement in f(X) recursively. For now, this just goes two
instructions up rather than one instruction up.