The macOS toolchain deprecated sprintf in favor of snprintf. This was blocking
the build on macOS. Replaced all instances of sprintf by snprintf.

From OpenACC 3.2 specification:
The async, wait, and device_type clauses may be specified on data
constructs.

This patch adds these clauses in the ACC.td file and adds some tests
for them in flang parsing.

Reviewed By: razvanlupusoru

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

The code generation of the fir.embox op creating descriptors for
array substring with a non constant length base was using the
substring length to compute the first dimension result stride.
Fix it to use the input length instead.

Reviewed By: PeteSteinfeld

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

`MCExpr::evaluateAsAbsolute` has a longstanding bug. When the MCAssembler is
non-null and the MCAsmLayout is null, it may incorrectly fold A-B even if A and
B are separated by a linker-relaxable instruction. This behavior can suppress
some ADD/SUB relocations and lead to wrong results if the linker performs
relaxation.

To fix the bug, ensure that linker-relaxable instructions only appear at the end
of an MCDataFragment, thereby making them terminate the fragment. When computing
A-B, suppress folding if A and B are separated by a linker-relaxable
instruction.

* `.subsection` now correctly give errors for non-foldable expressions.
* gen-dwarf.s will pass even if we add back the .debug_line or .eh_frame/.debug_frame code from D150004
* This will fix suppressed relocation when we add R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128.

In the future, we should investigate the desired behavior for
`MCExpr::evaluateAsAbsolute` when both MCAssembler and ...

Reviewed By: nikic

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

fir.rebox is emitting an llvm.sdiv to compute the character length
given the byte size from the input descriptor.
Inside a fir.global, this is not needed given the target length must
be accessible via the type, and it caused MLIR to fail LLVM IR
code generation (and crash).

Use the input type length when available instead.

Reviewed By: PeteSteinfeld, vzakhari

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

Followup to D153624. Allows for better exit count calculations for loops checking heap allocations against null.

Reviewed By: nikic

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

While we can disallow AAs, liveness checks are everywhere and if the
user doesn't want them it is costly to go through just to find out
everything is assumed live.

The interface was changed to return pointers, so we need to check them
for null now at they might actually be null in the future).

For variables with lvalue reference type in untied task loop,
it now wrongly sets its actual type as ElementType. It should
be converted to pointer type.

It fixes https://github.com/llvm/llvm-project/issues/62965

Reviewed By: ABataev

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

Clean up ahead of a patch to fix bugs in the AMDGPUDisassembler.

Use split-file to simplify and extend existing kernel-descriptor
disassembly tests.

Add a comment to AMDHSAKernelDescriptor.h, as at least one small set
towards keeping all kernel-descriptor sensitive code in sync.

Reviewed By: MaskRay, kzhuravl, arsenm

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

Name resolution was failing when the routine name is
a function/subroutine in the parent scope.

Reviewed By: vzakhari

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

Before:
```
c = //
'{default: 0};
```

After:
```
c = //
    '{default: 0};
```

If the line has to be broken, the continuation part should be
indented.  Before this fix, it was not the case if the continuation
part was a struct literal.  The rule that caused the problem was added
in 783bac6b.  It was intended for aligning the field labels in
ProtoBuf.  The type `TT_DictLiteral` was only for colons back then, so
the program didn't have to check whether the token was a colon when it
was already type `TT_DictLiteral`.  Now the type applies to more
things including the braces enclosing a dictionary literal.  In
Verilog, struct literals start with a quote.  The quote is regarded as
an identifier by the program.  So the rule for aligning the fields in
ProtoBuf applied to this situation by mistake.

Reviewed By: HazardyKnusperkeks

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

This adds a type_checked_load_relative intrinsic whose semantics it is to
load a relative function pointer.

A relative function pointer is a pointer to a 32bit value that when
added to its address yields the address of the function.

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

Extend the SourceFile class to take account of #line directives
when computing source file positions for error messages.
Adjust the output of #line directives to -E output so that they
reflect any #line directives that were in the input.

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

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

Change-Id: Idcc5c7c25dc350b8dc9a1865fd67982904d06ecd

The header for namespace symbol is barely useful.

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

We can't have a call with a constant target with a ptrauth bundle. Remove the
ptrauth bundle operand in such a case

rdar://105696396

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

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

Add an additional entry point so that CSE can be used without a pass. This allows CSE to be used from the Transform dialect without invalidating all handles.

* All IR modifications are done with a rewriter.
* The C++ entry point takes a `RewriterBase &`, which may have a listener attached to it. This allows users to track all IR modifications.

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

This change continues with the line of work discussed in https://discourse.llvm.org/t/riscv-transition-in-vector-pseudo-structure-policy-variants/71295. In D153155, we started removing the legacy distinction between unsuffixed (TA) and _TU pseudos. This patch continues that effort for the unary instruction families.

The change consists of a few interacting pieces:
* Adding a vector policy operand to VPseudoUnaryNoMaskTU.
* Then using VPseudoUnaryNoMaskTU for all cases where VPseudoUnaryNoMask was previously used and deleting the unsuffixed form.
* Then renaming VPseudoUnaryNoMaskTU to VPseudoUnaryNoMask, and adjusting the RISCVMaskedPseudo table to use the combined pseudo.
* Fixing up two places in C++ code which manually construct VMV_V_* instructions.

Normally, I'd try to factor this into a couple of changes, but in this case, the table structure is tied to naming and thus we can't really separate the otherwise NFC bits.

As before, we see codegen changes (some improvements and some regressions) due to scheduling differences caused by the extra implicit_def instructions.

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

[X86] LowerTRUNCATE - attempt to use PACKSS/PACKUS on AVX512 targets if the truncation source is concatenating from smaller subvectors

Don't just use AVX512 truncation ops if PACKSS/PACKUS can do this more cheaply

[X86] Add isFreeToSplitVector helper to detect nodes that we can freely split/extract subvectors from.

Helper wrapper around the existing collectConcatOps method.

This commit implements layout_right in support of C++23 mdspan
(https://wg21.link/p0009

). layout_right is a layout mapping policy
whose index mapping corresponds to the memory layout of multidimensional
C-arrays, and is thus also referred to as the C-layout.

Co-authored-by: Damien L-G <dalg24@gmail.com>

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

D120936 has made the loss of `__unaligned` qualifier NOT a bad-conversion.
Because of this, the bad-conversion note about the loss of this qualifier does not take effect.
e.g.
```
void foo(int *ptr);

void func(const __unaligned int *var) { foo(var); }
```
BEFORE this patch:
```
source.cpp:3:41: error: no matching function for call to 'foo'
    3 | void func(const __unaligned int *var) { foo(var); }
      |                                         ^~~
source.cpp:1:6: note: candidate function not viable: 1st argument ('const __unaligned int *') would lose __unaligned qualifier
    1 | void foo(int *ptr);
      |      ^
    2 |
    3 | void func(const __unaligned int *var) { foo(var); }
      |                                             ~~~
```
AFTER this patch:
```
source.cpp:3:41: error: no matching function for call to 'foo'
    3 | void func(const __unaligned int *var) { foo(var); }
      |                                         ^~~
source.cpp:1:6: note: candidate function not viable: 1st argument ('const __unaligned int *') would lose const qualifier
    1 | void foo(int *ptr);
      |      ^
    2 |
    3 | void func(const __unaligned int *var) { foo(var); }
      |                                             ~~~
```
Please note the different mentions of `__unaligned` and `const` in notes.

Reviewed By: cjdb, rnk
Differential Revision: https://reviews.llvm.org/D153690

The initial implementation of the modernize-use-std-print check was
capable of converting calls to printf (etc.) which used the return value
to calls to std::print which has no return value, thus breaking the
code.

Use code inspired by the implementation of bugprone-unused-return-value
check to ignore cases where the return value is used. Add appropriate
lit test cases and documentation.

Reviewed By: PiotrZSL

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

DWARFLinker has a compatibility feature with dsymutil-classic.
It may keep location expression attribute even if does not
reference live address. Current llvm-dwarfdump --verify
reports a error if variable references an address but is not
added into the .debug_names table.

error: Name Index @ 0x0: Entry for DIE @ 0xf35 (DW_TAG_variable) with name seed missing.

DW_TAG_variable
  DW_AT_name      ("seed")
  DW_AT_type      (0x00000000000047b7 "uint64_t")
  DW_AT_location  (DW_OP_addr 0x9ff8)  <<<< dead address

DWARFLinker does not add the variable into .debug_names table
because it references dead address. To have a valid variable and
consistent accelerator table it is necessary to remove location expression
referencing dead address. This patch removes dsymutil-classic
compatibilty feature.

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

Revert D152502 and instead optimize away copy from undefs, but clear the undef flag on the original copy.
Apparently, not optimizing the COPY can cause performance issues in some cases.

Fixes SWDEV-405813, SWDEV-405899

Reviewed By: arsenm

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

Add support for performing a link step on z/OS.  This will support C & C++ building executables and shared libs.

Reviewed By: zibi, abhina.sreeskantharajan

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

Reviewed By: ABataev

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

 Sometimes PHI have different incoming values, such as:
 ```
%1:vgpr_256 = COPY %0:agpr_256
%2:vgpr_32 = COPY %1:vgpr_256.sub0
```

Those weren't handled, which could lead to massive performance issues if break-large-PHIs kicked in + AGPRs were used (MFMA)

Fixes SWDEV-407986

Reviewed By: #amdgpu, arsenm

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

Currently getGEPCost uses the target type of the GEP as a heuristic for
the type that will be accessed, to pass onto isLegalAddressingMode.
Targets use this to work out if a GEP can then be folded into the
load/store instruction that uses the GEP.
For example, on RISC-V loads and stores can have an offset added to a
base register folded into a single instruction, so the following GEP is
free:

%p = getelementptr i32, ptr %base, i32 42       ; getInstructionCost = 0
%x = load i32, ptr %p                           ; getInstructionCost = 1
------------------------------------------------------------------------
lw t0, a0(42)

However vector loads and stores cannot have an offset folded into them,
so the following GEP is costed:

%p = getelementptr <2 x i32>, ptr %base, i32 42 ; getInstructionCost = 1
%x = load <2 x i32>, ptr %p                     ; getInstructionCost = 1
------------------------------------------------------------------------
addi  a0, 42
vle32 v8, (a0)

The issue arises whenever there is a mismatch between the target type of
the GEP and the type that is actually accessed:

%p = getelementptr i32, ptr %base, i32 42       ; getInstructionCost = 0
%x = load <2 x i32>, ptr %p                     ; getInstructionCost = 1
------------------------------------------------------------------------
addi  a0, 42
vle32 v8, (a0)

Even though this GEP will result in an add instruction, because TTI
thinks it's loading an i32, it will think it can be folded and not
charge for it.

The target type can become mismatched with the memory access during
transformations, noticeably during SLP where a scalar base pointer will
be reused to perform a vector load or store.

This patch adds an optional AccessType argument to getGEPCost which
allows the type of memory accessed by users to be passed in as a hint,
so that we can more accurately determine if the GEP can be folded into
its users.

If AccessType is not provided, getGEPCost falls back to the old
behaviour of using the PointeeType to guess the memory access type. This
can be revisited in a later patch.

Also for now, only GEPs with exactly one user use the access type hint.
Whilst we could look through all users and use all access types to
determine if we can fold the GEP, this patch avoids doing so to prevent
O(N) behaviour.

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

This patch updates the tests in gep.ll to have explicitly memory
accesses using them, to illustrate the new behaviour in D149889.
New tests have also been added for mismatched pointer types and memory
access types, and gep-zero-indices.ll has also been added to make sure
that we always cost GEPs with all zero indices as free.

Add `ViewLikeOpInterface` to `ExtractStridedMetadataOp` as it returns its buffer as one of the results.
Add mem Read/Write attributes to atomic ops.

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