It was using an incorrect attribute type, but the test was still passing
because of the value being present in the output.

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

`-loongarch-numeric-reg` for llvm-mc and llc.
`-M numeric` (which matches GNU objdump) for llvm-objdump and llvm-mc.

Reviewed By: SixWeining

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

These pattern names are inconsistent with current update_checks.py.

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

The code below currently prints less accurate values only on Windows 32-bit. On Windows, the default precision control on x87 is only 53-bit, and FADD triggers rounding with that precision, so the final result may be less accurate. This revision avoids less accurate conversions by using library calls instead.

```

int main() {
    int64_t n = 0b0000000000111111111111111111111111011111111111111111111111111111;
    printf("%lld, %.0f, %.0f", n, (float)n, (float)(uint64_t)n);

    return 0;
}
```

Reviewed By: craig.topper, lebedev.ri

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

This patch drops the ZeroBehavior parameter from bit counting
functions like countLeadingZeros.  ZeroBehavior specifies the behavior
when the input to count{Leading,Trailing}Zeros is zero and when the
input to count{Leading,Trailing}Ones is all ones.

ZeroBehavior was first introduced on May 24, 2013 in commit
eb91eac9.  While that patch did not
state the intention, I would guess ZeroBehavior was for performance
reasons.  The x86 machines around that time required a conditional
branch to implement countLeadingZero<uint32_t> that returns the 32 on
zero:

        test    edi, edi
        je      .LBB0_2
        bsr     eax, edi
        xor     eax, 31
.LBB1_2:
        mov     eax, 32

That is, we can remove the conditional branch if we don't care about
the behavior on zero.

IIUC, Intel's Haswell architecture, launched on June 4, 2013,
introduced several bit manipulation instructions, including lzcnt and
tzcnt, which eliminated the need for the conditional branch.

I think it's time to retire ZeroBehavior as its utility is very
limited.  If you care about compilation speed, you should build LLVM
with an appropriate -march= to take advantage of lzcnt and tzcnt.
Even if not, modern host compilers should be able to optimize away
quite a few conditional branches because the input is often known to
be nonzero from dominating conditional branches.

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

I am getting this error with `check-flang`:
```
ld.lld: error: undefined symbol: mlir::SuccessorRange::SuccessorRange(mlir::Operation*)
>>> referenced by Operation.h:549 (/llvm-project/llvm/../mlir/include/mlir/IR/Operation.h:549)
>>>               CMakeFiles/FlangRuntimeTests.dir/Allocatable.cpp.o:(mlir::Operation::getSuccessors())
```

The buildbots are okay, so I guess it has something to do with
gcc-9 that I am using.

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

This lets users of FunctionOpInterface finally have the
name/visibility accessors from SymbolOpInterface. This also
lets us remove the clunky "getName" method from FunctionOpInterface.

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

This allows for interfaces to define a set of "base classes",
which are interfaces whose methods/extra class decls/etc.
should be inherited by the derived interface. This more
easily enables combining interfaces and their dependencies,
without lots of awkard casting. Additional implicit conversion
operators also greatly simplify the conversion process.

One other aspect of this "inheritance" is that we also implicitly
add the base interfaces to the attr/op/type. The user can still
add them manually if desired, but this should help remove some
of the boiler plate when an interface has dependencies.

See https://discourse.llvm.org/t/interface-inheritance-and-dependencies-interface-method-visibility-interface-composition

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

SymbolOpInterface overrides the base classof to provide support
for optionally implementing the interface. This is currently placed
in the extraClassDeclarations, but that is kind of awkard given that
it requires underlying knowledge of how the base classof is implemented.
This commit adds a proper "extraClassOf" field to allow interfaces to
implement this, which abstracts away the default classof logic.

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

There are very few instances in which we use multiple files
for interface definitions (none upstream), and this allows
for including interfaces that shouldn't be generated (for
interface inheritance, dependencies, etc.)

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

We have WIP Fixables for local variables and this central part of the machinery
was dropping Fixables attached to local variables instead of keeping those and
dropping everything else.
We are in the process of rewriting our patches for emitting fixits after we
discovered a conceptual problem in our design.
That is why there's currently no tests that would've detected the issue but
that will change very shortly.

This reverts commit c79635cc. Since I
forgot the case for 32-bit machine.

mention developers to remember to touch the serializer after them
modified the field of decls

It is easy for the developers to forget to touch the serializer after
they add new field to decls. Then if the existing tests fail to catch
such cases, it may be a bug report from users some day. And it is
time-consuming to solve such bugs.

To mitigate the problem, I add the static_asserts in the serializer. So
that the developers can understand they need to modify the serializer
after they saw the static assertion failure. Although this can't solve
all the problems, I feel the current status can be much better.

Reviewed By: erichkeane

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

Issue #58168 describes the difficulty diagnosing stack size issues
identified by -Wframe-larger-than. For simple code, its easy to
understand the stack layout and where space is being allocated, but in
more complex programs, where code may be heavily inlined, unrolled, and
have duplicated code paths, it is no longer easy to manually inspect the
source program and understand where stack space can be attributed.

This patch implements a machine function pass that emits remarks with a
textual representation of stack slots, and also outputs any available
debug information to map source variables to those slots.

The new behavior can be used by adding `-Rpass-analysis=stack-frame-layout`
to the compiler invocation. Like other remarks the diagnostic
information can be saved to a file in a machine readable format by
adding -fsave-optimzation-record.

Fixes: #58168

Reviewed By: nickdesaulniers, thegameg

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

Reviewed By: vitalybuka

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

In non-coalescing IntervalMaps the value type should not be requried to be
equality-comparable.

D91464 introduced verbose tool loading, but the test check only considers Linux.
On macOS, the outputs are totally different, causing the regression afterwards.
This patch simply sets the test to XFAIL on macOS.

Fix #56833.

Reviewed By: jdoerfert

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

The next gen plugin adds the def of `DEBUG_PREFIX` in CMake, causing
compiler warning that `DEBUG_PREFIX` is defined multiple times. This patch simply
guards the macro def.

Reviewed By: jdoerfert

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

For the targets that have in their ABI the requirement that arguments and
return values are extended to the full register bitwidth, it is important
that calls when built also take care of this detail.

The OMPIRBuilder, AddressSanitizer, GCOVProfiling, MemorySanitizer and
ThreadSanitizer passes are with this patch hopefully now doing this properly.

Reviewed By: Eli Friedman, Ulrich Weigand, Johannes Doerfert

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

Currently, the NVPTX compilation toolchain can only be invoked either
through CUDA or OpenMP via `--offload-device-only`. This is because we
cannot build a CUDA toolchain without an accompanying host toolchain for
the offloading. When using `--target=nvptx64-nvidia-cuda` this results
in generating calls to the GNU assembler and linker, leading to errors.

This patch abstracts the portions of the CUDA toolchain that are
independent of the host toolchain or offloading kind into a new base
class called `NVPTXToolChain`. We still need to read the host's triple
to build the CUDA installation, so if not present we just assume it will
match the host's system for now, or the user can provide the path
explicitly.

This should allow the compiler driver to create NVPTX device images
directly from C/C++ code.

Reviewed By: tra

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

Change-Id: I46f2ced9ceac592c2a93a00631014a806d4b0693

In many cases, we can use an alias to avoid a symbolic relocations,
instead of using the public, interposable symbol. When the instrumented
function is in a COMDAT, we can use a hidden alias, and still avoid
references to discarded sections.

Previous versions of this patch allowed the compiler to name the
generated alias, but that would only be valid when the functions were
local. Since the alias may be used across TUs we use a more
deterministic naming convention, and add a ".local" suffix to the alias
name just as we do for relative vtables aliases.

https://reviews.llvm.org/rG20894a478da224bdd69c91a22a5175b28bc08ed9
removed an incorrect assertion on Mach-O which caused assertion failures in LLD.

We addressed the link errors under ThinLTO + PGO + CFI by being more
selective about which comdat functions can be given aliases.
Specifically, we now do not emit an alias in the case of a comdat
function with hidden visibility, since the alias would have the same
linkage and visibility, giving no benefit over using the symbol
directly. This also prevents LowerTypeTest from incorrectly updating the
dangling alias after GlobalOpt replaces uses, and introducing a
duplicate symbol.

Reviewed By: phosek

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

Reviewed By: vitalybuka

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

This patch fixes the inconsistent task state when hot team is not used.
When the primary thread executes `__kmp_join_call`, it calls `__kmp_free_team`,
where worker threads will get destroyed if not using hot team. The destroy of
worker threads also reset their task state. However, the primary thread's is not
reset. When the next parallel region is encountered, in `__kmp_task_team_sync`,
the task state of thread will be flipped. Since the state of primary thread is not
reset, it is still 1, but all the worker threads will be 0, this leads to the
inconsistent task state, causing those threads are using completely different
task team.

Fix #59190.

Reviewed By: tlwilmar

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

Summary:
This file is not formatted, which makes further changes to it more
difficult. Format it.

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

Address feedback in https://reviews.llvm.org/D102284#2755060

Reviewed By: yota9

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

Some bots are not happy with the way Error is returned here. Let's see if
std::moving it fixes this.

Every Clang instance uses an internal FileSystemStatCache to avoid
stating the same content multiple times. However, different instances
of Clang will contend for filesystem access for their initial stats
during HeaderSearch or module validation.

On some workloads, the time spent in the kernel in these concurrent
stat calls has been measured to be over 20% of the overall compilation
time. This is extremly wassteful when most of the stat calls target
mostly immutable content like a SDK.

This commit introduces a new tool `clang-stat-cache` able to generate
an OnDiskHashmap containing the stat data for a given filesystem
hierarchy.

The driver part of this has been modeled after -ivfsoverlay given
the similarities with what it influences. It introduces a new
-ivfsstatcache driver option to instruct Clang to use a stat cache
generated by `clang-stat-cache`. These stat caches are inserted at
the bottom of the VFS stack (right above the real filesystem).

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

Reviewed By: mysterymath

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

Reviewed By: rafauler

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

This way we highlight a particular unsafe subexpression by providing more accurate
source location than begin of an entire statement.

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

Some `TypeLoc`s are considered "sugar" and we go past them in
`GetTypeSourceInfoForDeclarator`. The problem is that we peel off only
the same kind of `TypeLoc` at the time which makes it impossible to
handle mixed sequences like
`AttributedTypeLoc - MacroQualifiedTypeLoc - AttributedTypeLoc - PointerTypeLoc`

In this situation, as shown in the added test, we don't get to
`PointerTypeLoc` and don't set its starLoc leaving it uninitialized.

Address FIXME and peel off "sugar" `TypeLoc`s regardless of their order.

rdar://102149264

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