Check that the SGPR arguments have the `inreg` attribute and the VGPR
arguments don't.

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

This reverts commit 043d03d2.

So we can use it in Pointer.h as well when debugging.

Print the symbolic values of Base and Offset if appropriate.

Add an API that allows removing multiple incoming phi values based
on a predicate callback, as suggested on D157621.

This makes sure that the removal is linear time rather than quadratic,
and avoids subtleties around iterator invalidation.

I have replaced some of the more straightforward users with the new
API, though there's a couple more places that should be able to use it.

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

When building a fatbinary, the driver invokes the compiler multiple
times with different "--target". (For example, with "-x cuda
--cuda-gpu-arch=sm_70" flags, clang will be invoded twice, once with
--target=x86_64_...., once with --target=sm_70) If we use
-fsplit-machine-functions or -fno-split-machine-functions for such
invocation, the driver reports an error.

This CL changes the behavior so:

  - "-fsplit-machine-functions" is now passed to all targets, for non-X86
    targets, the flag is a NOOP and causes a warning.

  - "-fno-split-machine-functions" now negates -fsplit-machine-functions (if
    -fno-split-machine-functions appears after any -fsplit-machine-functions)
    for any target triple, previously, it causes an error.

  - "-fsplit-machine-functions -Xarch_device -fno-split-machine-functions"
    enables MFS on host but disables MFS for GPUS without warnings/errors.

  - "-Xarch_host -fsplit-machine-functions" enables MFS on host but disables
    MFS for GPUS without warnings/errors.

Reviewed by: xur, dhoekwater

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

This was unused since commit dd2362a8 last year.

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

Since we also have VLST for rvv now, it is not clear to keep using `isVLSTBuiltinType`, so I added prefix SVE to it.

Reviewed By: paulwalker-arm

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

D52985/D57677 added a .gcc_except_table workaround, but the new behavior
doesn't match GNU assembler.
```
void foo();
int bar() {
  foo();
  try { throw 1; }
  catch (int) { return 1; }
  return 0;
}

clang --target=mipsel-linux-gnu -mmicromips -S a.cc
mipsel-linux-gnu-gcc -mmicromips -c a.s -o gnu.o

.uleb128 ($cst_end0)-($cst_begin0)     // bit 0 is not forced to 1
.uleb128 ($func_begin0)-($func_begin0) // bit 0 is not forced to 1
```

I have inspected `.gcc_except_table` output by `mipsel-linux-gnu-gcc -mmicromips -c a.cc`.
The `.uleb128` values are not forced to set the least significant bit.

In addition, D57677's adjustment (even->odd) to CodeGen/Mips/micromips-b-range.ll is wrong.
PC-relative `.long func - .` values will differ from GNU assembler as well.

The original intention of D52985 seems unclear to me. I think whatever
goal it wants to achieve should be moved to an upper layer.

This isMicroMips special case has ...

Tests were acidentally included into target executed on sanitizer-ppc64be-linux bot.
It does not look like there were OK before.

This didn't actually misclassify the resulting IR variable, but caused a
false-positive error about mismatched section flags.

Follow-up to D156726, issue identified by @eddyz87, thanks!

When a convergencectrl token is passed to a convergent call, and the called
function in turn calls the entry intrinsic, the intrinsic is now now replaced
with the convergencectrl token.

The spec requires the following check:
  A call from function F to function G can be inlined only if:
  - at least one of F or G does not make any convergent calls, or,
  - both F and G make the same kind of convergent calls: controlled or
    uncontrolled.

But this change does not implement this complete check. A proper implemenation
require a whole new analysis that identifies convergence in every function. For
now, we skip that and just do a cursory check for the entry intrinsic. The
underlying assumption is that in a compiler flow that fully implements
convergence control tokens, there is no mixing of controlled and uncontrolled
convergent operations in the whole program.

This is a reboot of the original change D85606 by
Nicolai Haehnle <nicolai.haehnle@amd.com>.

Reviewed By: arsenm, nhaehnle

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

limits.h currently interferes with Clang's limits.h. include_next
emits a warning because it is a GNU extension. Will re add this once
we figure out a good solution.

This reverts commits 13bbca8d,
002cba03, and
0fb30668.

This change adds tooltips over graph edges that indicate the to and
the from of the edge together with the probability for this edge.

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

Using monospace font for the IR in the graphs improves readability
over the default sans font.

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

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

This wouldn't affect the form @import as the test shows. The two
affected test case `diag-flags.cpp` and `diag-pragma.cpp` are old test
cases in 2017 and 2018, when we're not so clear about the direction of
modules. And the things that these 2 tests tested can be covered by
clang modules naturally. So I change the them into clang modules to
not block this patch.

This just expands on the existing logic that worked for `Or` and
applies it to any binop where `0` is the identity value on the RHS
i.e: `add`, `or`, `xor`, `shl`, etc...

Proofs For Some: https://alive2.llvm.org/ce/z/XZo6JD

Reviewed By: nikic

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

This is essentially NFC as the cases `decomposeBitTestICmp` covers
that weren't already covered explicitly, will be canonicalized into
the cases explicitly covered. As well the unsigned cases don't apply
as the `Mask` is not a power of 2.

That being said, using a well established helper is less bug prone and
if some canonicalization changes, will prevent regressions here.

Reviewed By: nikic

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

AFAICT, the trunc is not needed for correctness/performance and just
blocks what should be handlable cases.

Reviewed By: nikic

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

There was just alot of boolean logic to propegate conditions that seem
clearer in conditions.

Reviewed By: nikic

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

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

The actual callsite we are adding to doesn't need to be
`willreturn`/`nounwind`, only ever instructions between the callsite
and the return.

Reviewed By: nikic

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

We can do this by just querying attribute in the callsite itself. This
is both cleaner code and produces bette results.

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

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

Just a simple instruction save.

Proof: https://alive2.llvm.org/ce/z/Vb484j

Reviewed By: nikic

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

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

This commit refactors the implementation of VPReductionRecipe to use
reference instead of pointer for member RdxDesc. Because the member
RdxDesc in VPReductionRecipe should not be a nullptr, using a reference
will provide clearer semantics.

Reviewed By: fhahn

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

1. In X86LowerAMXType.cpp dyn_cast could lead to UserI be nullptr which coud be dref in IRBuilder constructor.
2. In AsmPrinter.cpp, doInitialization could make MMI be nullptr if MMIWP->getMMI() is false, then the deref after could be unexpected.

Reviewed By: skan

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

CMake Warning (dev) in tools/dsymutil/CMakeLists.txt:
  A logical block opening on the line

    /Users/jiefu/llvm-project/llvm/tools/dsymutil/CMakeLists.txt:42 (if)

  closes on the line

    /Users/jiefu/llvm-project/llvm/tools/dsymutil/CMakeLists.txt:44 (endif)

  with mis-matching arguments.
This warning is for project developers.  Use -Wno-dev to suppress it.

LLDB doesn't yet have a TypeSystemRust implemented however it is used to debug Rust applications. Most of the types map well enough to Clang types and there are python formatters implemented to display those types reasonably well in a debugger.

However, Rust enums are completely ignored by LLDB as Clang never emits DW_TAG_variant_part inside DW_TAG_structure_type

This diff adds a parser for DW_TAG_variant_part (Rust-only) that creates a matching valid Clang declaration to the Rust enum. As long as there is enough information and all fields have correct offsets synthetic/summary providers can be implemented to display it correctly when debugging Rust code

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

Reland "[modules] Fix error about the same module being defined in different .pcm files when using VFS overlays."

Fixing Windows buildbot by not using "BuildTemporaries/module.modulemap"
because it is interpreted as defining a module in "BuildTemporaries" directory.

Fix errors like
> module 'MultiPath' is defined in both 'path/to/modules.cache/3JR48BPRU7BCG/MultiPath-1352QHUF8RNMU.pcm' and 'path/to/modules.cache/3JR48BPRU7BCG/MultiPath-20HNSLLIUDDV1.pcm'

To avoid building extra identical modules `-ivfsoverlay` option is not a
part of the hash like "/3JR48BPRU7BCG/". And it is build system's
responsibility to provide `-ivfsoverlay` options that don't cause
observable differences.  We also need to make sure the hash like
"-1352QHUF8RNMU" is not affected by `-ivfsoverlay`. As this hash is
defined by the module map path, use the path prior to any VFS
remappings.

rdar://111921464

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

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

This patch makes use of the HLFIR box produced for hlfir.declare
in place of the FIR box (the memref of hlfir.declare) when possible.

This makes the representation a little bit more clear, because
all accesses are made via a single box.
This reduces the life range of the original box, because the new
temporary box produced by embox/rebox is used from now.
Apparently, this works around some issues in the current HLFIR codegen,
for example, look at the LIT tests changes around fir.array_coor
produced by hlfir.designate codegen - using the FIR box for fir.array_coor
might result in using incorrect lbounds.
Apparently, this change enables more intrinsics simplifications
because the SimplifyIntrinsicsPass looks for explicit embox/rebox
in findBoxDef() to decide whether to apply the optimization.
This change also provides better association of the base addresses
referenced by OpenACC clauses with the corresponding boxes
that might be used explicitly in OpenACC regions (e.g. for reading
the lbounds).

Reviewed By: razvanlupusoru, clementval

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

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