For some builtins, we need to do quite a bit of type checking ourselves,
so pass the call expression along. This way we can inspect arguments,
expected return value, etc.

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

/Users/jiefu/llvm-project/llvm/lib/IR/Instructions.cpp:166:3: error: ignoring return value of function declared with 'nodiscard' attribute [-Werror,-Wunused-result]
  std::remove_if(const_cast<block_iterator>(block_begin()),
  ^~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

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

This reverts commit 2628fa33 since
it broke the multicall driver build.

This patch is extracted from D96035, it adds support for the existing
DWARFLinker functionality. What is not supported yet:

1. Types deduplication(--odr mode).
2. Modules deduplication.
3. Generation of index tables.

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

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 caused problems to fix MCAssembler::relaxLEB to use evaluateAsAbsolute instead of evaluateKnownAbsolute,
which is needed to proper support R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128.

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

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