This reverts commit 8480063f.

We're seeing some test failures on our builders.

These were missed in D110784.

This reverts commit 019041be.

It broke some bots.

This is to simplify an upcoming change where we distinguish between
flavors of libc++ by adding an apple-libc++ Lit feature.

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

This patch makes instruction-referencing accepts an additional scenario
where values can be read from physical registers at the start of blocks. As
far as I was aware, this only happened:
 * With arguments in the entry block,
 * With constant physical registers,

To which this patch adds a third case:
 * With exception-handling landing-pad blocks

In the attached test: the operand of the dbg.value traces back to the
"landingpad" instruction, which becomes some copies from physregs. Right
now, that's deemed unacceptable, and the assertion fires. The fix is to
just accept this scenario; this is a case where the value in question is
defined by a register and a position, not by an instruction that defines
it. Reading it with a DBG_PHI is the correct behaviour, there isn't a
non-copy instruction that we can refer to.

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

We keep a map from function name to source location so we don't have to
do it via looking up a source location from the AST. However, since
function names can be long, we actually use a hash of the function name
as the key.

Additionally, we can't rely on Clang's printing of function names via
the AST, so we just demangle the name instead.

This is necessary to implement
https://lists.llvm.org/pipermail/cfe-dev/2021-September/068930.html.

Reviewed By: dblaikie

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

When we check if a load is loop invariant by finding a dominating
invariant.start call, we strip bitcasts until we get to an i8* Value,
and look for an invariant.start use of the i8* Value.

We may accidentally end up at an i8 global and look at a global's uses,
which we shouldn't do in a loop pass. Although we could make this
logic work with globals, that's not currently intended.

Reviewed By: nikic

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

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

This change adds the High Precision Decimal described here:
https://nigeltao.github.io/blog/2020/parse-number-f64-simple.html
It will be used for the atof implementation later, but is complete and
tested now.

The code is inspired by the golang implmentation of the HPD class, which
can be found here: https://github.com/golang/go/blob/release-branch.go1.16/src/strconv/decimal.go

Reviewed By: sivachandra

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

And run update_test_checks.py on hoisting.ll.

Per the GCC info page:

    If the function is declared 'extern', then this definition of the
    function is used only for inlining.  In no case is the function
    compiled as a standalone function, not even if you take its address
    explicitly.  Such an address becomes an external reference, as if
    you had only declared the function, and had not defined it.

Respect that behavior for inline builtins: keep the original definition, and
generate a copy of the declaration suffixed by '.inline' that's only referenced
in direct call.

This fixes holes in c3717b68.

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

This fixes some typos in OpDefinitions.md and DeclarativeRewrites.md,
and wrap function/class names in backticks.

Reviewed By: mehdi_amini

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

A bunch of MTE tests like ./ScudoUnitTest-aarch64-Test/MemtagTest.StoreTags
can fail on aarch64-linux if the kernel doesn't support the tagged address ABI. It looks like
the call to prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0) can return -1, which
casted to an unsigned int and masked will return a value not equal to
PR_MTE_TCF_NONE, meaning systemDetectsMemoryTagFaultsTestOnly can return an incorrect value.

This updates the check to account for a failing prctl call.

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

When determining NoAlias based on object size and dereferenceability
information, we can ignore frees for the same reason we can ignore
possible null pointers (if null is not a valid pointer): Actually
accessing the null pointer / freed pointer would be immediate UB,
and AA results are only valid under the assumption of an access.

This addresses a minor regression from D110745.

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

The builtins: `__compare_and_swaplp`, `__fetch_and_addlp`,
` __fetch_and_andlp`, `__fetch_and_orlp`, `__fetch_and_swaplp` are
64 bit only. This patch ensures the compiler produces an error in 32 bit mode.

Reviewed By: #powerpc, nemanjai

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

reviewers: klausler, PeteSteinfeld

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

The delayed stack protector feature which is currently used for SDAG (and thus
allows for more commonly generating tail calls) depends on being able to extract
the tail call into a separate return block. To do this it also has to extract
the vreg->physreg copies that set up the call's arguments, since if it doesn't
then the call inst ends up using undefined physregs in it's new spliced block.

SelectionDAG implementations can do this because they delay emitting register
copies until  *after* the stack arguments are set up. GISel however just
processes and emits the arguments in IR order, so stack arguments always end up
last, and thus this breaks the code that looks for any register arg copies that
precede the call instruction.

This patch adds a thunk argument to the assignValueToReg() and custom assignment
hooks. For outgoing arguments, register assignments use this return param to
return a thunk that does the actual generating of the copies. We collect these
until all the outgoing stack assignments have been done and then execute them,
so that the copies (and perhaps some artifacts like G_SEXTs) are placed after
any stores.

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

The discussion in https://reviews.llvm.org/D110425 demonstrated that "packing"
may be a confusing term to define the behavior of this op in presence of the
attribute. Instead, indicate the intended effect of preventing the folder from
being applied.

Reviewed By: nicolasvasilache, silvas

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

This reverts commit 90da0b9a.

It was causing an LLVM_ENABLE_EXPENSIVE_CHECKS buildbot failure.

This provides better support for `TypeLoc`s to allow `TypeLoc`-related
matchers to feature stricter typing and to avoid relying on the dynamic
casting of `TypeLoc`s in matchers.

Reviewed By: ymandel, tdl-g, sbenza

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

G_SEXT seems to be unnecessary here, anyext will do.

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

Update clang to treat vector unsigned long long and friends as invalid
for AltiVec without VSX.

Reported in: https://bugs.llvm.org/show_bug.cgi?id=47782

Reviewed By: nemanjai, amyk

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

fir.array_update is only handling intrinsic assignments.
They are two big differences with user defined assignments:
1. The LHS and RHS types may not match, this does not play well
   with fir.array_update that relies on both the merge and the
   updated element to have the same type.
2. user defined assignment has a call semantics, with potential
   side effects. So if a fir.array_update can hide a call, it traits
   would need to be updated.

Instead of hiding more semantic in the fir.array_update, introduce
a new fir.array_modify op that allows de-correlating indicating that
an array value element is modified, and how it is modified.
This allow the ArrayValueCopy pass to still perform copy elision
while not having to implement the call itself, and could in general
be used for all kind of assignments (e.g. character assignment).

Update the alias analysis to not rely on the merge arguments (since
fir.array_modify has none).
Instead, analyze what is done with the element address.
This implies adding the ability to follow the users of fir.array_modify,
as well as being able to go through fir.store that may be generated to
store the RHS value in order to pass it to a user define routine.
This is done by adding a ReachCollector class to gather all array
accesses.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: schweitz

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



Co-authored-by: Valentin Clement <clementval@gmail.com>

I'm disabling it to avoid blocking everybody until I've fixed the issue.

Fix some clang-tidy wrning in flang/Optimizer/Support and
remove explicit number of inlined elements for SmallVector. This
is mostly to sync with the changes from fir-dev.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: schweitz

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

Both ports are required for BitScan ops. Update the port usage and distributed throughput based off the most recent llvm-exegesis captures (PR36895) and what Intel AoM / Agner reports as well.

Also remove some redundancy because the source and result
types of any multiply are always the same.

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

This splits out the logic from shouldChangeType() that
currently allows 8/16/32-bit transforms even if those
types are not listed as legal in the data layout.

This could be useful as a predicate for vector
insert/extract transforms.

Note that this leaves the subsequent checks in
shouldChangeType() unchanged. We may want to merge
the checks for i1 and/or "ToLegal" into "isDesirable",
but that may alter existing transforms.

We were previously just ignoring unreachable, but targets like Darwin want to
keep unreachable instructions as traps.

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

The LE Power sanitizer bot fails when testing standalone compiler-rt due to
an MSAN test warning introduced by -Wbitwise-instead-of-logical. As this option
along with -Werror is enabled on the bot, the test failure occurs.
This patch updates msan_test.cpp to fix the warning introduced by the
-Wbitwise-instead-of-logical.

In working on D106362 I found that a few more tests were needed. I've
been asked to pre-push the tests for that ticket. This should complete
the tests needed for now.

AArch64StorePairSuppress will prevent the creation of LDP's based on
scheduling info. This shouldn't apply when optimizing for size though,
where the size decrease should be considered more important.

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