The machine hosting these agents will be down
for maintenance June 2nd.

We (Linaro) will remove this once the agents are back online.

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

The implementations of VPlanDominatorTree, VPlanLoopInfo and VPlanPredicator
are all incompatible with modeling loops in VPlans as region without
explicit back-edges.

Those pieces are not actively used and only exercised by a few gtest
unit tests. They are at the moment blocking progress towards unifying
the native and inner-loop vectorizer paths in D121624 and D123005.

I think we should not block forward progress on unused pieces of code,
so this patch removes the utilities for now. The plan is to re-introduce
them as needed in a way that is compatible with the unified VPlan scheme
used in both the inner loop vectorizer and the native path.

Reviewed By: sguggill

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

Paths that start with `\\?\` are absolute paths, and aren't expected
to be used with wildcard expressions.

Previously, the `?` at the start of the path triggered the condition
for a potential wildcard, which caused the path to be split and
reassembled. In builds with `LLVM_WINDOWS_PREFER_FORWARD_SLASH=ON`,
this caused a path like e.g. `\\?\D:\tmp\hello.cpp` to be reassembled
into `\\?\D:\tmp/hello.cpp` which isn't a valid path (as such
absolute paths must use backslashes consistently).

This fixes https://github.com/mstorsjo/llvm-mingw/issues/280.

I'm not sure if there's any straightforward way to add a test
for this case, unfortunately.

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

It's a fairly common issue that the generating code incorrectly marks
instructions as narrow or wide; check that the instruction lengths
add up to the expected value, and error out if it doesn't. This allows
catching code generation bugs.

Also check that prologs and epilogs are properly terminated, to
catch other code generation issues.

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

Use the packed unwind info format if possible; otherwise try to
create a packed epilog.

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

This includes .seh_* directives for generating it from assembly.
It is designed fairly similarly to the ARM64 handling.

For .seh_handler directives, such as
".seh_handler __C_specific_handler, @except" (which is supported
on x86_64 and aarch64 so far), the "@except" bit doesn't work in
ARM assembly, as '@' is used as a comment character (on all current
platforms).

Allow using '%' instead of '@' for this purpose. This convention
is used by GAS in similar contexts already,
e.g. [1]:

    Note on targets where the @ character is the start of a comment
    (eg ARM) then another character is used instead. For example the
    ARM port uses the % character.

In practice, this unfortunately means that all such .seh_handler
directives will need ifdefs for ARM.

Contrary to ARM64, on ARM, it's quite common that we can't evaluate
e.g. the function length at this point, due to instructions whose
length is finalized later. (Also, inline jump tables end with
a ".p2align 1".)

If unable to to evaluate the function length immediately, emit
it as an MCExpr instead. If we'd implement splitting the unwind
info for a function (which isn't implemented for ARM64 yet either),
we wouldn't know whether we need to split it though.

Avoid calling getFrameIndexOffset() on an unset
FuncInfo.UnwindHelpFrameIdx, to avoid triggering asserts in the
preexisting testcase CodeGen/ARM/Windows/wineh-basic.ll. (Once
MSVC exception handling is fully implemented, those changes
can be reverted.)

[1] https://sourceware.org/binutils/docs/as/Section.html#Section

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

For ARM SEH, the epilogs will need a little more associated data than
just the plain list of opcodes.

This is a preparatory refactoring for D125645.

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

Upstream the code for handling loops with real control variables from
the fir-dev branch at
https://github.com/flang-compiler/f18-llvm-project/tree/fir-dev/



Also add a test.

Loops with real-valued control variables are always lowered to
unstructured loops. The real-valued control variables are handled the
same as integer ones, the only difference is that they need to use
floating point instructions instead of the integer equivalents.

Co-authored-by: V Donaldson <vdonaldson@nvidia.com>

Reviewed By: martong

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

Reviewed By: frasercrmck

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

This patch adds parser support for defaultmap clause [OpenMP 5.0].

Reviewed By: kiranchandramohan, peixin, shraiysh

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

Add tangent operation for complex dialect. This is the follow-up change of https://reviews.llvm.org/D126521

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

Make the SimpleSValBuilder to be able to look up and use a constraint
for an operand of a SymbolCast, when the operand is constrained to a
const value.
This part of the SValBuilder is responsible for constant folding. We
need this constant folding, so the engine can work with less symbols,
this way it can be more efficient. Whenever a symbol is constrained with
a constant then we substitute the symbol with the corresponding integer.
If a symbol is constrained with a range, then the symbol is kept and we
fall-back to use the range based constraint manager, which is not that
efficient. This patch is the natural extension of the existing constant
folding machinery with the support of SymbolCast symbols.

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

Similar to procedure argument, the function result cannot be one
named constant.

Reviewed By: klausler

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

While working on a clang-format option RemoveBracesLLVM that removes
braces following the guideline, we were unsure about what to do with
the braces of do-while loops. The ratio of using to omitting the
braces is about 4:1 in the llvm-project source, so it will help to
add an example to the guideline.

Also cleans up the original examples including making the nested if
example more targeted on avoiding potential dangling else situations.

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

Clang Tidy check cert-oop57-cpp now checks for arbitrary-valued
arguments in memset expressions containing non-trivially
default-constructible instances. Previously it only checked literal 0 values.

Reviewed By: aaron.ballman

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

Revert to fix a ReleaseNote issue.

This reverts commit d33f1999.

Clang Tidy check cert-oop57-cpp now checks for arbitrary-valued
arguments in memset expressions containing non-trivially
default-constructible instances. Previously it only checked literal 0 values.

Reviewed By: aaron.ballman

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

As mentioned in D125947, we can reduce codegen results by
adding an explicit hard single-float ABI.

Reviewed By: luismarques

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

-march is error-prone: -march inherits the OS and environment from the default
target triple. Use -mtriple which is more common.

Add FLAGS option for add_header_library, add_object_library,
add_entrypoint_object, and add_libc_unittest.

In general, a flag is a string provided for supported functions under the
multi-valued option `FLAGS`.  It should be one of the following forms:
  FLAG_NAME
  FLAG_NAME__NO
  FLAG_NAME__ONLY
A target will inherit all the flags of its upstream dependency.

When we create a target `TARGET_NAME` with a flag using (add_header_library,
add_object_library, ...), its behavior will depend on the flag form as follow:
- FLAG_NAME: The following 2 targets will be generated:
    `TARGET_NAME` that has `FLAG_NAME` in its `FLAGS` property.
    `TARGET_NAME.__NO_FLAG_NAME` that depends on `DEP.__NO_FLAG_NAME` if
       `TARGET_NAME` depends on `DEP` and `DEP` has `FLAG_NAME` in its `FLAGS`
       property.
- FLAG_NAME__ONLY: Only generate 1 target `TARGET_NAME` that has `FLAG_NAME`
    in its `FLAGS` property.
- FLAG_NAME__NO: Only generate...

This reverts commit e2ee8bf9.

This change is beyond my ability to integrate into Google's internal
build configuration tonight.

In CSKYConstantIslands, when fix up an unconditional branch(CSKY::BR32) whose destination is
too far away to fit in its displacement field, and if the R15(LR) register has been
spilled in the prologue, then we can use BSR to implement a far jump. So we need estimate function
size, and spill R15(LR) when the function size >= unconditional branch(CSKY::BR32) can reach.

EstimateFunctionSizeInBytes function adds up all instructions and constant pool entries(each entry is 4 bytes).

-march=hexagon uses the default target triple and changes the arch part of
hexagon. On linux-musl, this essentially becomes hexagon-unknown-linux-musl
which has different code generation. Use -mtriple instead.

Link: https://github.com/llvm/llvm-project/issues/48936

For some reason, we implemented the xx_stxvp intrinsics
to require a const pointer. This absolutely doesn't make
sense for a store. Remove the const from the definition.

Currently, the Bazel build uses static, checked in [llvm-]config.h files
in combination with global macro definitions to mimic CMake's generated
headers. This change reuses the write_cmake_config.py script from the GN
build to generate the headers from source in the same way. The purpose
is to ensure that the Bazel build stays up to date with any changes to
the CMake config files. The write_cmake_config.py script has good error
checking to ensure that unneeded, stale variables are not passed, and
that any missing variables are reported as errors.

I tried to closely follow the logic in the GN build here:
  llvm/utils/gn/secondary/llvm/include/Config/BUILD.gn
The duplication between this file and config.bzl is significant, and we
could consider going further, but I'd like to hold off on it for now.

The GN build changes are to move the write_cmake_config.py script up to
//llvm/utils/write_cmake_config.py, and update the paths accordingly.

The next logical change is to generate Clang's config.h header.

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

Reuse -Xoffload-linker option for HIP toolchain.

Reviewed by: Artem Belevich

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

clang by default assumes static library name to be xxx.lib
when -lxxx is specified on Windows with MSVC environment,
instead of libxxx.a.

This patch fixes static device library unbundling for that.
It falls back to libxxx.a if xxx.lib is not found.

Reviewed by: Artem Belevich

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

The patch addresses the feature request from https://github.com/ClangBuiltLinux/linux/issues/1633. The implementation borrows a lot from aarch64.

Reviewed By: nickdesaulniers, MaskRay

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

After D126484, order in .debug-line-str and .debug-line is different. Changed
test accordingly.

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

Previous couple commits replaced SANITIZER_MAC with SANITIZER_APPLE in bulk.
This change will prompt anyone still trying to use SANITIZER_MAC to rename.

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

Create dxc_D as alias to option D which Define <macro> to <value> (or 1 if <value> omitted).

Reviewed By: aaron.ballman

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

Summary:
While disassembling instructions, we need to replace certain immediate
operands with symbols. This symbolizing process relies on reading
relocations against instructions. However, some X86 instructions can
have multiple immediate operands and up to two relocations against
them. Thus, correctly matching a relocation to an operand is not
always possible without knowing the operand offset within the
instruction.

Luckily, LLVM provides an interface for passing the required info from
the disassembler via a virtual MCSymbolizer class. Creating a
target-specific version allows a precise matching of relocations to
operands.

This diff adds X86MCSymbolizer class that performs X86-specific
symbolizing (currently limited to non-branch instructions).

Reviewers: yota9, Amir, ayermolo, rafauler, zr33

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

This patch does the same thing as D125886 did.

- Use `Overloaded` rather than `Mangled`.
- Use `Prototype` or `Desc` rather than `Seq`, it's not just a string
sequence.

Reviewed By: fakepaper56

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