When building with `LLVM_BUILD_EXTERNAL_COMPILER_RT=ON` (e.g. Swift does
this) we do an "external" build of compiler-rt where we build
compiler-rt with the just built clang.

Unfortunately building in this mode had a bug where compiler-rt would
not get rebuilt if compiler-rt sources changed. This is problematic
for incremental builds because it meant that the compiler-rt binaries
were stale.

The fix is to use the `BUILD_ALWAYS` ExternalProject_Add option which
means the build command for compiler-rt is always run.

In principle if all of the following are true:

* compiler-rt has already been built.
* there are no compiler-rt source changes.
* the compiler hasn't changed.
* ninja is being used as the generator for the compiler-rt build.

then the overhead for always running the build command for incremental
builds is negligible.

However, in practice clang gets rebuilt everytime the HEAD commit
changes (due to commit hash being embedded in the output of `--version`)
which means all of compiler-rt will be rebuilt everytime this happens.
While this is annoying it's better to do the slow but correct thing
rather than the fast but incorrect thing.

rdar://75150660

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

You can define a base type with a type-bound procedure which is erroneously
missing a NOPASS attribute and then define another type that extends the base
type and overrides the erroneous procedure.  In this case, when we perform
semantic checking on the overriding procedure, we verify the "pass index" of
the overriding procedure.  The attempt to get the procedure's pass index fails
a call to CHECK().

I fixed this by calling SetError() on the symbol of the overridden procedure in
the base type.  Then, I check HasError() before executing the code that invokes
the failing call to CHECK().  I also added a test that will cause the compiler
to fail the call to CHECK() without this change.

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

Split out the common base of Linux hardware breakpoint/watchpoint
support for AArch64 into a Utility class, and use it to implement
the matching support on FreeBSD.

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

[InstCombine][SimplifyLibCalls] An extra sqrtf was produced because of transformations in optimizePow function

See: https://bugs.llvm.org/show_bug.cgi?id=47613

There was an extra sqrt call because shrinking emitted a new powf and at the same time optimizePow replaces the previous pow with sqrt and as the result we have two instructions that will be in worklist of InstCombie despite the fact that %powf is not used by anyone (it is alive because of errno).

As the result we have two instructions:

  %powf = call fast float @powf(float %x, float 5.000000e-01)
  %sqrt = call fast double @sqrt(double %dx)

%powf will be converted to %sqrtf on a later iteration.

As a quick fix for that I moved shrinking to the end of optimizePow so that pow is replaced with sqrt at first that allows not to emit a new shrunk powf.

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

The type legalizer will visit the result before the operands. To
avoid creating an illegal target specific node or falling back to
scalarization, we need to manually split vector operands.

This still doesn't handle the case of non-power of 2 operands
which need to be widened. I'm not sure the type legalizer is
ready for it. I think we would need to insert an
INSERT_SUBVECTOR with the power of 2 type we want, with an undef
first operand, and the non-power of 2 orignal operand as the vector
to insert. Then fill in the neutral elements into the elements the
padded elements. Alternatively we INSERT_SUBVECTOR into a neutral vector.
From there we carry on splitting if needed to get to a legal type
then do the target specific code.

The problem with this is the type legalizer doesn't know how to
widen an insert_subvector yet. We would need to add that including
the handling for a non-undef first vector.

Reviewed By: frasercrmck

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

This reverts commit df9158c9.

This patch adds handling for DBG_VALUE_LIST in the MIR-passes (after
finalize-isel), excluding the debug liveness passes and DWARF emission. This
most significantly affects MachineSink, which now needs to consider all used
registers of a debug value when sinking, but for most passes this change is
simply replacing getDebugOperand(0) with an iteration over all debug operands.

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

This is a part of https://reviews.llvm.org/D95835.

Reviewed-by: morehouse

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

In https://reviews.llvm.org/D98283, the RUN line in pre-fir-tree04.f90
was updated to use `%flang_fc1` instead of `%f18` (so that the test is
shared between the old and the new driver). Unfortunately, the new
driver does not know yet how to find standard intrinsics modules. As a
result, the test fails when `FLANG_BUILD_NEW_DRIVER` is set to On.

I'm restoring the original RUN line. This is rather straightforward, so
sending without a review. This should make Flang builders happy.

Follow up for fhahn's D98284. Also fixes a case from PR47644.

Reviewed By: fhahn

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

D57708 changed SIInstrInfo::isReallyTriviallyReMaterializable to reject
V_MOVs with extra implicit operands, but it accidentally rejected all
V_MOVs because of their implicit use of exec. Fix it but avoid adding a
moderately expensive call to MI.getDesc().getNumImplicitUses().

In real graphics shaders this changes quite a few vgpr copies into move-
immediates, which is good for avoiding stalls on GFX10.

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

This reverts commit 429c6ecb.

The PFT has been updated to support Fortran 77.
clang-tidy cleanup.

Authors: Val Donaldson, Jean Perier, Eric Schweitz, et.al.

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

The LR is stored to off-stack spill area where it is vulnerable.
"paciasp" add an auth code to the LR while the "autiasp" verifies that so
LR can't be modiifed on the spill area.

Test: build with -DCMAKE_C_FLAGS="-mbranch-protection=standard",
run on Armv8.3 capable hardware with PAuth.

Reviewed By: eugenis

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

Rename ELF specific variables, making it easier to add the XPLink
variables in future patches.

Reviewed By: abhina.sreeskantharajan, Kai

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

This reverts commit 0da27ba5.

This revision was causing an error on the sanitizer-x86_64-linux-autoconf build.

The flag doesn't (and shouldn't) have an effect in that case.
ld64 doesn't warn on this, but it seems like a good thing to do.
If it causes problems in practice for some reason, we can revert it.

Also add a dedicated test for install_name.

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

lld doesn't read MH_DEAD_STRIPPABLE_DYLIB to strip dead dylibs yet,
but now it can produce dylibs with it set.

While here, also switch an existing test that looks only at the main Mach-O
header from --all-headers to --private-header.

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

Link `MLIRStandardToLLVM` to `MLIRAVX512Transforms`, since
the latter uses `LLVMTypeConverter` defined in the first one.

Reviewed By: ftynse

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

This patch allows DBG_VALUE_LIST instructions to be emitted to DWARF with valid
DW_AT_locations. This change mainly affects DbgEntityHistoryCalculator, which
now tracks multiple registers per value, and DwarfDebug+DwarfExpression, which
can now emit multiple machine locations as part of a DWARF expression.

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

Refactor cross file rename to use a Filesystem instead of a function for getting buffer contents of open files.

Depends on D94554

Reviewed By: sammccall

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

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

It is good to have a combined `divrem` instruction when the
`div` and `rem` are computed from identical input operands.
Some targets can lower them through a single expansion that
computes both division and remainder. It effectively reduces
the number of instructions than individually expanding them.

Reviewed By: arsenm, paquette

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

This reverts commit 8080ea4c.

As discussed offline we should only do that for debug builds.

There are 5 occurrences FIME and 15333 FIXME. All of them should be FIXME.

Reviewed By: alexfh

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

If it was decided to relocate derived pointer using the spill its value is
not exported in general case.
When gc.relocate is located in an another block than a statepoint we cannot
get SD for derived value but for spill case it is not required at all.
However implementation of gc.relocate lowering unconditionally request SD value
causing the assert triggering.

The CL fixes this by handling spill case earlier than SD is really required.

Reviewers: reames, dantrushin
Reviewed By: dantrushin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D98324

This patch adds support for DBG_VALUE_LIST in the LiveDebugVariables pass. The
changes are mostly in computeIntervals, extendDef, and addDefsFromCopies; when
extending the def of a DBG_VALUE_LIST the live ranges of every used register
must be considered, and when such a def is killed by more than one of its used
registers being killed at the same time it is necessary to find valid copies of
all of those registers to create a new def with.

The DebugVariableValue class has also been changed to reference multiple
location numbers instead of just one. This has been accomplished by using a
C-style array with a unique_ptr and an array length packed into 6 bits, to
minimize the size of the class (which must be kept low to be used with
IntervalMap). This may not be the most efficient solution possible, and should
be looked at if performance issues arise.

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

These were not updated when squashing LLVMArmNeon and ArmNeon dialects.

This patch adds `-fdebug-dump-parsing-log` in the new driver. This option is
semantically identical to `-fdebug-instrumented-parse` in `f18` (the
former is added as an alias in `f18`).

As dumping the parsing log makes only sense for instrumented parses, we
set Fortran::parser::Options::instrumentedParse to `True` when
`-fdebug-dump-parsing-log` is used. This is consistent with `f18`.

To facilitate tweaking the configuration of the frontend based on the
action being requested, `setUpFrontendBasedOnAction` is introduced in
CompilerInvocation.cpp.

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

The dialect separation was introduced to demarkate ops operating in different
type systems. This is no longer the case after the LLVM dialect has migrated to
using built-in vector types, so the original reason for separation is no longer
valid. Squash the two dialects into one.

The code size decrease isn't quite large: the ops originally in LLVM_AVX512 are
preserved because they match LLVM IR intrinsics specialized for vector element
bitwidth. However, it is still conceptually beneficial to have only one
dialect. I originally considered to use Tablegen multiclasses to define both
the type-polymorphic op and its two intrinsic-related instantiations, but
decided against it given both the complexity of the required Tablegen input and
its dissimilarity with the rest of ODS-defined ops, both potentially resulting
in very poor maintainability.

Depends On D98327

Reviewed By: nicolasvasilache, springerm

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

VectorOfLengthAndType accepts a cartesian product of given lengths and types
rather than types produced by co-indexed values in the corresponding lists.
Update the definitions accordingly. The type validity is already enforced by
op traits.

Reviewed By: nicolasvasilache, springerm

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

Moved getStaticLoopRanges and getStaticShape methods to LinalgInterfaces.td to add static shape verification

It is to use the methods in LinalgInterfaces.cpp for additional static shape verification to match the shaped operands and loop on linalgOps. If I used the existing methods, I would face circular dependency linking issue. Now we can use them as methods of LinalgOp.

Reviewed By: hanchung

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

As thakis reported, I will replace `rm -r` by `rm -rf`.
I hope it fixes the build bot.

Until now we've been maintaining 2 test directories for Flang's drivers:
  * test/Driver for `f18` (the current driver)
  * test/Flang-Driver for `flang-new` (the new driver)
As we have started sharing tests between the drivers, this separation is
no longer required. This patch merges the two test directories. As
suggested in the review, moving forward we'll avoid having tests
specifically for the old driver.

A few notable changes:
  * Driver/version-test.f90 and Driver/no-files.f90 are deleted. The
  versions for the new driver are more robust, but tricky to share.
  * Driver/write-module.f90 is deleted in favour of
    Flang-Driver/write-module.f90 (see https://reviews.llvm.org/D97197
    for more context)

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

If the non-iterator side of an iterator operation
`+`, `+=`, `-` or `-=` is `UndefinedVal` an assertions happens.
This small fix prevents this.

Patch by Adam Balogh.

Reviewed By: NoQ

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

Before `bc713f6a` landed, the analyzer
crashed on this reduced example.
It seems important to have bot `ctu` and `-analyzer-opt-analyze-headers`
enabled in the example.

This test file ensures that no regression happens in the future in this regard.

Reviewed By: martong, NoQ

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

According to a Bugzilla ticket (https://bugs.llvm.org/show_bug.cgi?id=45148),
ArrayBoundCheckerV2 produces a false-positive report.
This patch adds a test demonstrating the current //flawed// behavior.
Also adds several similar test cases just to be on the safe side.

Reviewed By: martong

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