Currently, the regcall calling conversion in Clang doesn't match with
ICC when passing / returning structures. https://godbolt.org/z/axxKMKrW7

This patch tries to fix the problem to match with ICC.

Reviewed By: LuoYuanke

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

This reverts commit 6faba31e.

It may cause "offset is outside the section".

We have the same code repeated in both callers, sink it into callee.

The motivation here isn't just code style, we can also defer the relatively expensive aliasing checks until the cheap structural preconditions have been validated.  (e.g. Don't bother aliasing if src is not an alloca.)  This helps compile time significantly.

If we vectorize a e.g. store, we leave around a bunch of getelementptrs for the individual scalar stores which we removed. We can go ahead and delete them as well.

This is purely for test output quality and readability. It should have no effect in any sane pipeline.

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

A Block is optionally allocated & leaks in case of failed parse. Inline the
function and ensure Block gets freed unless parse is successful.

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

GlobalISel is used in option -O0, so add MOVI pattern for it,
which is done similar in gcc.(https://godbolt.org/z/8j6fzG3h6)

Fix https://github.com/llvm/llvm-project/issues/53651

Reviewed By: dmgreen, paquette

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

we will get warning:```parameter ‘op’ set but not used``` when template function with empty template parameter list.

Reviewed By: jpienaar

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

Reviewed By: ldionne

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

This reverts commit 7dda44c1.

Reviewed By: craig.topper

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

Inline assembly is scary but we need to support it for the OpenMP GPU
device runtime. The new assumption expresses the fact that it may not
have call semantics, that is, it will not call another function but
simply perform an operation or side-effect. This is important for
reachability in the presence of inline assembly.

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

Before we gave up if a call through bitcast had parameter attributes.
Interestingly, we allowed attributes for the return value already. We
now handle both the same way, namely, we drop the ones that are
incompatible with the new type and keep the rest. This cannot cause
"more UB" than initially present.

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

Reviewed By: arsenm

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

glibc sysdeps/aarch64/tst-vpcs-mod.S has something like:
```
.variant_pcs    vpcs_call
.global vpcs_call
```

This is supported by GNU as but leads to an error in MC. Use getOrCreateSymbol
to support a not-yet-registered symbol: call `registerSymbol` to ensure the
symbol exists even if there is no binding directive/label, to match GNU as.

While here, improve tests to check (1) a local symbol can get
STO_AARCH64_VARIANT_PCS (2) undefined .variant_pcs (3) an alias does not
inherit STO_AARCH64_VARIANT_PCS.

Reviewed By: efriedma

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

Reviewed By: abrachet

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

Reviewed By: luismarques

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

This makes Fuchsia consistent with Linux on AArch64.

Reviewed By: abrachet

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

The clang driver to picks up compiler runtime files using full paths.
Without this, at least for aarch64, the driver tries to pick up the
compiler runtime files from the working directory.

Reviewed By: michaelrj

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

Platforms may define uintptr_t differently, so perform an explicit cast

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

Use a separate templated QuarantineBlocks class to avoid a zero-length array

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

Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks rely on 2 invariants:

1) For frontend instrumentation, MD_prof branch_weights will always be
   populated before llvm.expect intrinsics are lowered.

2) for IR and sample profiling, llvm.expect intrinsics will always be
   lowered before branch_weights are populated from the IR profiles.

These invariants allow the checking to assume how the existing branch
weights are populated depending on the profiling method used, and emit
the correct diagnostics. If these invariants are ever invalidated, the
MisExpect related checks would need to be updated, potentially by
re-introducing MD_misexpect metadata, and ensuring it always will be
transformed the same way as branch_weights in other optimization passes.

Frontend based profiling is now enabled without using LLVM Args, by
introducing a new CodeGen option, and checking if the -Wmisexpect flag
has been passed on the command line.

Reviewed By: tejohnson

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

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:472:16: warning: enumeration value 'HLSL' not handled in switch [-Wswitch]
    switch (IK.getLanguage()) {
               ^

.eh_frame pieces may be dropped due to GC/ICF. When --emit-relocs adds
relocations against .eh_frame, the offsets need to be adjusted. Use the same
way as MergeInputSection with a special case handling outSecOff==-1 for an
invalid piece (see eh-frame-marker.s).

This exposes an issue in mips64-eh-abs-reloc.s that we don't reliably
handle anyway. Just add --no-check-dynamic-relocations to paper over it.

Original patch by Ayrton Muñoz

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

Seeing a test failure with asan in Halide generated code, reverting
while I investigate.

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

* Improve eh-frame-merge.s
* Delete invalid .eh_frame+5 test in ehframe-relocation.s

Been >2 weeks since flipped to Both, following update procedure and
flipping to prefixed.

This builtin returns the address of a global instance of the
`std::source_location::__impl` type, which must be defined (with an
appropriate shape) before calling the builtin.

It will be used to implement std::source_location in libc++ in a
future change. The builtin is compatible with GCC's implementation,
and libstdc++'s usage. An intentional divergence is that GCC declares
the builtin's return type to be `const void*` (for
ease-of-implementation reasons), while Clang uses the actual type,
`const std::source_location::__impl*`.

In order to support this new functionality, I've also added a new
'UnnamedGlobalConstantDecl'. This artificial Decl is modeled after
MSGuidDecl, and is used to represent a generic concept of an lvalue
constant with global scope, deduplicated by its value. It's possible
that MSGuidDecl itself, or some of the other similar sorts of things
in Clang might be able to be refactored onto this more-generic
concept, but there's enough special-case weirdness in MSGuidDecl that
I gave up attempting to share code there, at least for now.

Finally, for compatibility with libstdc++'s <source_location> header,
I've added a second exception to the "cannot cast from void* to T* in
constant evaluation" rule. This seems a bit distasteful, but feels
like the best available option.

Reviewers: aaron.ballman, erichkeane

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

Been >2 weeks since flipped to Both, following update procedure and
flipping to prefixed.

There's a vulnerability in 1.2.11:
https://twitter.com/taviso/status/1508438583484452866

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

Calling an ObjC method from a C function marked with the 'enforce_tcb'
attribute did not produce a warning. Now it does, and on top of that
Objective-C methods can participate in TCBs themselves.

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

First of all, this is the convention: all other tools have their
dependencies private. While it does not have an effect on linking
(there is no linking against executables), it does have an effect
on exporting: having the targets private allows installing the tools
without the libraries in a statically linked build, or a build against
libclang-cpp.so.

Reviewed By: v.g.vassilev

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

Not sure if this could use more testing, but hopefully this is adequate.

This is a fix for #53963.

Reviewed By: aaron.ballman

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

Fixes #54513

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

Bringing in HLSL as a language as well as language options for each of
the HLSL language standards.

While the HLSL language is unimplemented, this patch adds the
HLSL-specific preprocessor defines which enables testing of the command
line options through the driver.

Reviewed By: pete, rnk

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

This patch makes -version valid, and --version invalid, for
flang-new -fc1. The invocation
  flang-new --version
remains valid. This behaviour is consistent with clang
(and with clang -cc1 and clang -cc1as).

Previously, flang-new -fc1 accepted --version (as per Options.td), but
the frontend driver acutally checks for -version. As a result,
  flang-new -fc1 --version
triggered no action, emitted no message, and stalled waiting for
standard input.

Fixes #51438

Reviewed By: PeteSteinfeld, awarzynski

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

STB_GNU_UNIQUE should be treated in a way similar to STB_GLOBAL.
This fixes an "Invalid Binding" failure in an LLVM_ENABLE_ASSERTIONS=on build
for source files like glibc elf/tst-unique1mod1.c .

This bug has been benign so far because (a) Clang does not produce
%gnu_unique_object by itself (b) a non-assertion build likely picks the
STB_GLOBAL code path anyway.