This was a TODO for the move to C++14. Now that the move has been completed, we can resolve it.

We have this extra step in wasm-ld that doesn't exist in other lld
backend which verifies the existing contents of the relocation targets.
This was originally intended as an extra form of double checking and an
aid to compiler developers.   However it has always been somewhat
controversial and there have been suggestions in the past the we simply
remove it.

My motivation for removing it now is that its causing me a headache
when trying to fix an issue with negative addends.  In the case of
negative addends that final result can be wrapped/negative but this
checking code would require significant modification to be able to deal
with that case.  For example with some test cases I'm looking at I'm
seeing error like this:

```
wasm-ld: warning: /usr/local/google/home/sbc/dev/wasm/llvm-build/tools/lld/test/wasm/Output/merge-string.s.tmp.o:(.rodata_relocs): unexpected existing value for R_WASM_MEMORY_ADDR_I32: existing=FFFFFFFA expected=FFFFFFFFFFFFFFFA
```

Rather than try to refactor `calcExpectedValue` to somehow return two
different types of results (32 and 64-bit) depending on the relocation
type, I think we can just remove this code.

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

ProcessGDBRemote plugin layers.

Also fix a bug where if we tried to interrupt, but the ReadPacket
wakeup timer woke us up just after the timeout, we would break out
the switch, but then since we immediately check if the response is
empty & fail if it is, we could end up actually only giving a
small interval to the interrupt.

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

Fix for substitutes-in-compile-flags.sh.cpp to run it properly on Windows platform.

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

The OpenMP spec seems to require the compound operators be used for
+, *, &, |, and ^ reduction.  So use these if a class has those operators.
If not try the simple operators as we did previously to limit the impact
to existing code.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=48584

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

-fno-semantic-interposition (only effective with -fpic) can optimize default
visibility external linkage (non-ifunc-non-COMDAT) variable access and function
calls to avoid GOT/PLT, by using local aliases, e.g.
```
int var;
__attribute__((optnone)) int fun(int x) { return x * x; }
int test() { return fun(var); }
```

-fpic (var and fun are dso_preemptable)
```
test:
.LBB1_1:
        auipc   a0, %got_pcrel_hi(var)
        ld      a0, %pcrel_lo(.LBB1_1)(a0)
        lw      a0, 0(a0)
// fun is preemptible by default in ld -shared mode. ld will create a PLT.
        tail    fun@plt
```

vs -fpic -fno-semantic-interposition (var and fun are dso_local)
```
test:
.Ltest$local:
.LBB1_1:
        auipc   a0, %pcrel_hi(.Lvar$local)
        addi    a0, a0, %pcrel_lo(.LBB1_1)
        lw      a0, 0(a0)
// The assembler either resolves .Lfun$local at assembly time (-mno-relax
// -fno-function-sections), or produces a relocation referencing a non-preemptible
// local symbol (which can avoid PLT).
        tail    .Lfun$local
```

Note: Clang's default -fpic is more aggressive than GCC -fpic: interprocedural
optimizations (including inlining) are available but local aliases are not used.
-fpic -fsemantic-interposition can disable interprocedural optimizations.

Depends on D101875

Reviewed By: luismarques

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

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

This way we don't have to duplicate i32/f32 and i64/f64 entries,
which was already forgotten to be done for a few tuples.

GlobalOpt implements a heap SROA (SROA for an malloc allocatated struct or array
of structs) which is largely undertested (heap-sra-[1234].ll are basically the
same test with very little difference) and does not trigger at all when
bootstrapping clang (it only supports the case of one single store).

The heap SROA implementation causes PR50027 (GEP is not properly handled; crash or miscompile).
Just drop the implementation. I have deleted some obviously duplicated tests
but kept `heap-sra-[12]{,-no-nullopt}.ll`.

Reviewed By: aeubanks

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

This needs some tablegen changes so that we can actually import the patterns properly.

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

Similar to X86 D73230 and AArch64 D101872

With this change, we can set dso_local in clang's -fpic -fno-semantic-interposition mode,
for default visibility external linkage non-ifunc-non-COMDAT definitions.

For such dso_local definitions, variable access/taking the address of a
function/calling a function will go through a local alias to avoid GOT/PLT.

Reviewed By: jrtc27, luismarques

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

Make sure the alignment of the generated operations matches the
alignment of the byval argument.  Previously, we were just ignoring
alignment and getting lucky.

While I'm here, also delete the unnecessary "tail" handling.
Passing a pointer to a byval argument to a "tail" call is UB, so
rewriting to an alloca doesn't require any special handling.

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

This is useful for dialects that have logical subparts.

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

On Windows, the permission bits are mapped down to essentially only
two possible states; readonly or readwrite. Normalize the checked
permission bitmask to match what the implementation will return.

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

This fixes PR46992.

Git stores symlinks as text files and we should not format them even if
they have one of the requested extensions.

(Move the call to `cd_to_toplevel()` up a few lines so we can also print
the skipped symlinks during verbose output.)

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

clang sometimes passes this flag along (see D68351), so we should implement it.

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

This reapplies 6d263b6f (which was reverted in 1c7c6f2b) with a fix for a
CMake issue.

We sometimes unroll an ac-implied-do of an array constructor into a flat list
of values.  We then re-analyze the array constructor that contains the
resulting list of expressions.  Such a list may or may not contain errors.

But when processing an array constructor with an unrolled ac-implied-do, the
compiler was building an expression to represent the extent of the resulting
array constructor containing the list of values.  The number of operands
in this extent expression was based on the number of elements in the
unrolled list of values.  For very large lists, this created an
expression so large that it could not be evaluated by the compiler
without overflowing the stack.

I fixed this by continuously folding the extent expression as each operand is
added to it.  I added the test .../flang/test/Semantics/array-constr-big.f90
that will cause the compiler to seg fault without this change.

Also, when the unrolled ac-implied-do expression contains errors, we were
repeating the same error message referencing the same source line for every
instance of the erroneous expression in the unrolled list.  This potentially
resulted in a very long list of messages for a single error in the source code.

I fixed this by comparing the message being emitted to the previously emitted
message.  If they are the same, I do not emit the message.  This change is also
tested by the new test array-constr-big.f90.

Several of the existing tests had duplicate error messages for the same source
line, and this change caused differences in their output.  So I adjusted the
tests to match the new message emitting behavior.

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

Change llvm_unreachable message from "Unknown llvm.MachO.PlatformKind
enum" to "Unknown llvm::MachO::PlatformKind enum".

Differential revision: https://reviews.llvm.org/D102250

This reverts commit 6d263b6f while I investigate the CMake failures that it
causes in some configurations.

Reland "[Coverage] Fix branch coverage merging in FunctionCoverageSummary::get() for instantiation""

Originally landed in: 6400905a
Reverted in: 668dccc3

Fix branch coverage merging in FunctionCoverageSummary::get() for instantiation
groups.

This change corrects the implementation for the branch coverage summary to do
the same thing for branches that is done for lines and regions.  That is,
across function instantiations in an instantiation group, the maximum branch
coverage found in any of those instantiations is returned, with the total
number of branches being the same across instantiations.

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

[X86][SSE] Add tests for permute(phaddw(phaddw(x,y),phaddw(z,w))) -> phaddw(phaddw(),phaddw()) folds.

We currently only fold if NumEltsPerLane == 4

For some reason clang-10 can't match the expected errors produced by
passing icomplete arrays to range access functions. Disabling the tests
is a stop-gap solution to fix the bots.

My thought process is that if v2i64 is an LMUL=1 type then v2i32
should be an LMUL=1/2 type. We limit the fractional LMUL so that
SEW=64 clips to LMUL=1, SEW=32 clips to LMUL=1/2, etc. This
ensures there's always a fractional LMUL available to truncate a type.
This does reduce the number of vsetvlis in some cases.

Some tests increase vsetvlis because the best container type for a
mask type is dependent on the LMUL+SEW that the mask was produced
from, but you can't tell that from the type. I think this is
something we need to solve this in the machine IR when optimizing
vsetvlis.

Reviewed By: frasercrmck

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

I've seen this in the RawSpeed's BitPumpMSB*::push() hotpath,
after fixing the buffer abstraction to a more sane one,
when looking into a +5% runtime regression.
I was hoping that this would fix it, but it does not look it does.

This seems to be at least not worse than the original pattern.
But i'm actually mainly interested in the case where we already
compute `(y+32)` (see last test),

https://alive2.llvm.org/ce/z/ZCzJio

Reviewed By: spatel

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

Limited to splats because we would need to truncate the shift
amount vector otherwise.

I tried to do this with new ISD nodes and a DAG combine to
avoid such a large pattern, but we don't form the splat until
LegalizeDAG and need DAG combine to remove a scalable->fixed->scalable
cast before it becomes visible to the shift node. By the time that
happens we've already visited the truncate node and won't revisit it.

I think I have an idea how to improve i64 on RV32 I'll save for a
follow up.

Reviewed By: frasercrmck

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

This reverts commit 6400905a.

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

[libomptarget][nfc] Add hook to easily disable building amdgcn bclib

This is useful when building LLVM with a toolchain that can't emit code
for amdgcn, e.g. because it overrides the include search path with headers
from another architecture, or the clang compiler is missing builtins.

Reviewed By: tianshilei1992

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

This is actually necessary for correctness, as memref.reinterpret_cast
doesn't verify if the output shape doesn't match the static sizes.

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

A type system is not guaranteed to have a symbol file. This patch adds null-pointer checks so we don't crash when trying to access a type system's symbol file.

Reviewed By: aprantl, teemperor

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

Change Target::ReadMemory to ensure the amount of memory read from the file-cache is the amount requested.

This change ensures that if for whatever reason we read less bytes than expected (for example, when trying to read memory that spans multiple sections), we try reading from the live process as well.

Reviewed By: jasonmolenda

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

groups.

This change corrects the implementation for the branch coverage
summary to do the same thing for branches that is done for lines and regions.
That is, across function instantiations in an instantiation group, the maximum
branch coverage found in any of those instantiations is returned, with the
total number of branches being the same across instantiations.

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

Summary:
Test and produce warning for subtracting a pointer from null or subtracting
null from a pointer.  Reuse existing warning that this is undefined
behaviour.  Also add unit test for both warnings.

Reformat to satisfy clang-format.

Respond to review comments:  add additional test.

Respond to review comments:  Do not issue warning for nullptr - nullptr
in C++.

Fix indenting to satisfy clang-format.

Respond to review comments:  Add C++ tests.

Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: efriedma (Eli Friedman), nickdesaulniers (Nick Desaulniers)
Differential Revision: https://reviews.llvm.org/D98798

Since D87304, `align` become an invalid attribute on none pointer types and
verifier will reject bitcode that has invalid `align` attribute.

The problem is before the change, DeadArgumentElimination can easily
turn a pointer return type into a void return type without removing
`align` attribute. Teach Autograde to remove invalid `align` attribute
from return types to maintain bitcode compatibility.

rdar://77022993

Reviewed By: dexonsmith

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