Reapply "Fix crash on switch conditions of non-integer types in templates"

This patch reapplies commit 76945821b9cad3. The first version broke
buildbots due to clang-tidy test fails. The fails are because some
errors in templates are now diagnosed earlier (does not wait till
instantiation). I have modified the tests to add checks for these
diagnostics/prevent these diagnostics. There are no additional code
changes.

Summary of code changes:

Clang currently crashes for switch statements inside a template when the
condition is a non-integer field member because contextual implicit
conversion is skipped when parsing the condition. This conversion is
however later checked in an assert when the case statement is handled.
The conversion is skipped when parsing the condition because
the field member is set as type-dependent based on its containing class.
This patch sets the type dependency based on the field's type instead.

This patch fixes Bug 40982.

Reviewers: rnk, gribozavr2

Patch by: Elizabeth Andrews (eandrews)

Differential revision: https://reviews.llvm.org/D69950

[ThinLTO] Fix bug when importing writeonly variables

Patch enables import of write-only variables with non-trivial initializers
to fix linker errors. Initializers of imported variables are converted to
'zeroinitializer' to avoid promotion of referenced objects.

Differential revision: https://reviews.llvm.org/D70006

[cmake] Remove SVN support from VersionFromVCS.cmake

Reviewers: phosek

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

[PowerPC][compiler-rt][builtins]Fix __fixunstfti builtin on PowerPC

__fixunstfti converts a long double (IBM double-double) to an unsigned 128 bit
integer.  This patch enables it to handle a previously unhandled case in which
a negative low double may impact the result of the conversion.

Collaborated with @masoud.ataei and @renenkel.
Patch By: Baptiste Saleil

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

Properly propagate is_variadic.

This fixes a copy&paste error made when adapting to new clang API
which was promptly caught by the bots.

[ELF] Suggest extern "C" when the definition is mangled while an undefined reference is not

The definition may be mangled while an undefined reference is not.
This may come up when (1) the reference is from a C file or (2) the definition
misses an extern "C".

(2) is more common. Suggest an arbitrary mangled name that matches the
undefined reference, if such a definition exists.

  ld.lld: error: undefined symbol: foo
  >>> referenced by a.o:(.text+0x1)
  >>> did you mean to declare foo(int) as extern "C"?
  >>> defined in: a1.o

Reviewed By: dblaikie, ruiu

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

[ELF] Suggest extern "C" when an undefined reference is mangled while the definition is not

When missing an extern "C" declaration, an undefined reference may be
mangled while the definition is not. Suggest the missing
extern "C" and the base name.

Reviewed By: ruiu

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

[JumpThreading] Fix a comment typo (NFC)

Reviewers: kazu

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

remove redundant LLVM version from version string when setting CLANG_VENDOR

Summary:
When downstream LLVM distributions (like AOSP) set the CLANG_VENDOR
cmake variable, the version string printed by the clang driver looks
like:

$ clang --version
[CLANG_VENDOR] clang version X.X.X ([CLANG_REPOSITORY_STRING] sha) (based on LLVM X.X.X)

Rather than the more standard:
$ clang --version
clang version X.X.X ([CLANG_REPOSITORY_STRING] sha)

Based on feedback the the version string is a little long, the trailing
"(based on LLVM X.X.X)" is redundant and makes less sense after moving
LLVM to the monorepo. And it is only added should vendors set the cmake
variable CLANG_VENDOR. Let's remove it.

Reviewers: jyknight, eli.friedman, rsmith, rjmccall, efriedma

Reviewed By: efriedma

Subscribers: arphaman, efriedma, cfe-commits, srhines

Tags: #clang

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

Revert "[LVI] Normalize pointer behavior"

This reverts commit 15bc4dc9a8949f9cffd46ec647baf0818d28fb28.

clang-cmake-x86_64-sde-avx512-linux buildbot reported quite a few
compile-time regressions in test-suite, will investigate.

[lldb] Make Asan/SIP workaround work for Python 3

Make the check generic instead of hard-coding the path to Python 2. This
also fixes the print-syntax to be compatible with both versions.

[lldb] Prevent Asan/SIP workaround from affecting Python in /usr/local/bin

The code that works around SIP was unintentionally being triggered for
/usr/local/bin/python as well. That caused trouble on GreenDragon where
we were swapping out a Python 3 executable with the system's Python 2
executable.

Fix two typos in one test name, three days before its 10th birthday! (NFC)

Adapt LLDB to clang API change in ObjCMethodDecl::create().

[LVI] Normalize pointer behavior

Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.

The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.

This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this change not fully NFC, because we can now fold
terminator icmps based on the dereferencability information in the
same block. This is the reason why I changed one JumpThreading test
(it would optimize the condition away without the change).

Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.

I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.

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

PODSmallVector - fix uninitialized variable warnings. NFCI.

TimeTraceProfiler - fix uninitialized variable warning. NFCI.

Obj2YamlError - fix uninitialized variable warning. NFCI.

CrashRecoveryContextCleanup - fix uninitialized variable warnings. NFCI.

Remove default values from constructor.

Redeclare Objective-C property accessors inside the ObjCImplDecl in which they are synthesized.

This patch is motivated by (and factored out from)
https://reviews.llvm.org/D66121 which is a debug info bugfix. Starting
with DWARF 5 all Objective-C methods are nested inside their
containing type, and that patch implements this for synthesized
Objective-C properties.

1. SemaObjCProperty populates a list of synthesized accessors that may
   need to inserted into an ObjCImplDecl.

2. SemaDeclObjC::ActOnEnd inserts forward-declarations for all
   accessors for which no override was provided into their
   ObjCImplDecl. This patch does *not* synthesize AST function
   *bodies*. Moving that code from the static analyzer into Sema may
   be a good idea though.

3. Places that expect all methods to have bodies have been updated.

I did not update the static analyzer's inliner for synthesized
properties to point back to the property declaration (see
test/Analysis/Inputs/expected-plists/nullability-notes.m.plist), which
I believed to be more bug than a feature.

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

rdar://problem/53782400

[LICM] Support hosting of dynamic allocas out of loops

This patch implements a correct, but not terribly useful, transform. In particular, if we have a dynamic alloca in a loop which is guaranteed to execute, and provably not captured, we hoist the alloca out of the loop. The capture tracking is needed so that we can prove that each previous stack region dies before the next one is allocated. The transform decreases the amount of stack allocation needed by a linear factor (e.g. the iteration count of the loop).

Now, I really hope no one is actually using dynamic allocas. As such, why this patch?

Well, the actual problem I'm hoping to make progress on is allocation hoisting. There's a large draft patch out for review (https://reviews.llvm.org/D60056), and this patch was the smallest chunk of testable functionality I could come up with which takes a step vaguely in that direction.

Once this is in, it makes motivating the changes to capture tracking mentioned in TODOs testable. After that, I hope to extend this to trivial malloc free regions (i.e. free dominating all loop exits) and allocation functions for GCed languages.

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

[LICM] Hoisting of widenable conditions out of loops

The change itself is straight forward and obvious, but ... there's an existing test checking for exactly the opposite. Both I and Artur think this is simply conservatism in the initial implementation.  If anyone bisects a problem to this, a counter example will be very interesting.

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

[CostModel] Fixed isExtractSubvectorMask for undef index off end

ShuffleVectorInst::isExtractSubvectorMask, introduced in
  [CostModel] Add SK_ExtractSubvector handling to getInstructionThroughput (PR39368)

erroneously thought that
%340 = shufflevector <4 x float> %339, <4 x float> undef, <3 x i32> <i32 2, i32 3, i32 undef>

is a subvector extract, even though it goes off the end of the parent
vector with the undef index. That then caused an assert in
BasicTTIImplBase::getExtractSubvectorOverhead.

This commit fixes that, by not considering the above a subvector
extract.

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

Change-Id: I87b8b00b24bef19ffc9a1b82ef4eca3b8a246eaf

[PowerPC] Remove redundant CRSET/CRUNSET in custom lowering of known CR bit spills

We lower known CR bit spills (CRSET/CRUNSET) to load and spill the known value
but forgot to remove the redundant spills.

e.g., This sequence was used to spill a CRUNSET:
    crclr   4*cr5+lt
    mfocrf  r3,4
    rlwinm  r3,r3,20,0,0
    stw     r3,132(r1)

Custom lowering of known CR bit spills lower it to:
    crxor 4*cr5+lt, 4*cr5+lt, 4*cr5+lt
    li  r3,0
    stw r3,132(r1)

crxor is redundant if there is no use of 4*cr5+lt so we should remove it

Differential revision: https://reviews.llvm.org/D67722

raw_ostream - fix static analyzer warnings. NFCI.
 - uninitialized variables
 - make BufferKind a scoped enum class

YAMLTraits.h - fix uninitialized variable warning. NFCI.

libclc: Drop the old python based build system

Reviewer: tstellar
Differential Revision: https://reviews.llvm.org/D69966

libclc: Drop travis

It only works for standalone repos.

Reviewer: tstellar
Differential Revision: https://reviews.llvm.org/D69965

[lldb] Skip parts of TestCallOverriddenMethod.py on Linux

The function call and the constructor call fail now several Linux
bots (Swift CI, my own bot and Stella's Debian system), so let's disable
the relevant test parts until we can figure out why it is failing.

[NFC] ConstantRange::subWithNoWrap(): fixup comment

[ConstantRange] Add umul_sat()/smul_sat() methods

Summary:
To be used in `ConstantRange::mulWithNoOverflow()`,
may in future be useful for when saturating shift/mul ops are added.

These are precise as far as i can tell.

I initially though i will need `APInt::[us]mul_sat()` for these,
but it turned out much simpler to do what `ConstantRange::multiply()`
does - perform multiplication in twice the bitwidth, and then truncate.
Though here we want saturating signed truncation.

Reviewers: nikic, reames, spatel

Reviewed By: nikic

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

[APInt] Add saturating truncation methods

Summary:
The signed one is needed for implementation of `ConstantRange::smul_sat()`,
unsigned is for completeness only.

Reviewers: nikic, RKSimon, spatel

Reviewed By: nikic

Subscribers: hiraditya, dexonsmith, llvm-commits

Tags: #llvm

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

find_interesting_reviews.py: avoid crash on non-ascii data.

OutputStream - fix static analyzer warnings. NFCI.
 - uninitialized variables
 - make getBufferCapacity() const

directory_entry - fix uninitialized variable warning. NFCI.

Timer - fix uninitialized variable warnings. NFCI.

ReplacementItem - fix uninitialized variable warning. NFCI.

Hashing - fix uninitialized variable warnings. NFCI.

[clang-format] Ensure dump_format_style.py can generate ClangFormatStyleOptions.rst without manual intervention

Summary:
This revision is the last in a series of revisions to return `clang/doc/tools/dump_format_style.py` to be being able to parse Format.h without needing to manually merge the ClangFormatStyleOptions.rst file.

The final modification to dump_format_style.py is needed following the addition of a  nested enumeration inside a nested structure following the introduction of {D68296}

Prior  related revisions will allow for a fully clang-formatted `clang/include/clang/Format/Format.h` to once again be used at the source.
{D69951}
{D69433}
{D69404}

Reviewers: mitchell-stellar, klimek, sammccall, owenpan

Reviewed By: mitchell-stellar

Subscribers: cfe-commits

Tags: #clang-format, #clang

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

[llvm-xray] Add AArch64 to llvm-xray extract

This required adding support for resolving R_AARCH64_ABS64 relocations to
get accurate addresses for function names to resolve.

Authored by: ianlevesque (Ian Levesque)
Reviewers: dberris, phosek, smeenai, tetsuo-cpp
Differential Revision: https://reviews.llvm.org/D69967

gn build: Merge 0dc0572b48e

[XCOFF][AIX] Differentiate usage of label symbol and csect symbol

Summary:
 We are using symbols to represent label and csect interchangeably before, and that could be a problem.
There are cases we would need to add storage mapping class to the symbol if that symbol is actually the name of a csect, but it's hard for us to figure out whether that symbol is a label or csect.

This patch intend to do the following:
    1. Construct a QualName (A name include the storage mapping class)
       MCSymbolXCOFF for every MCSectionXCOFF.
    2. Keep a pointer to that QualName inside of MCSectionXCOFF.
    3. Use that QualName whenever we need a symbol refers to that
       MCSectionXCOFF.
    4. Adapt the snowball effect from the above changes in
       XCOFFObjectWriter.cpp.

Reviewers: xingxue, DiggerLin, sfertile, daltenty, hubert.reinterpretcast

Reviewed By: DiggerLin, daltenty

Subscribers: wuzish, nemanjai, mgorny, hiraditya, kbarton, jsji, llvm-commits

Tags: #llvm

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

[AMDGPU][MC] Corrected src0 for v_movrelsd_b32 and v_movrelsd_2_b32

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

Reviewers: arsenm, rampitec

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

[LV] Apply sink-after & interleave-groups as VPlan transformations (NFCI)

This recommits 100e797adb433724a17c9b42b6533cd634cb796b (reverted in
009e032634b3bd7fc32071ac2344b12142286477 for failing an assert). While the
root cause was independently reverted in eaff3004019f97c64c88ab76da6b25106b659b30,
this commit includes a LIT to make sure IVDescriptor's SinkAfter logic does not
try to sink branch instructions.

BinaryStream - fix static analyzer warnings. NFCI.
 - uninitialized variables
 - documention warnings
 - shadow variable names

[clang-format] update comments in clang-format.py for python3 compatibility

Summary:
D23319 introduced python3 compatibility to clang-format.py, this is however not reflected by the documentation in the comments at the beginning of the file, which show how to use the script with python2 in .vimrc. While the actual mapping a user might want to use may well differ from my suggestion, I think it's nice to show the python2 and python3 version, such that a user can pick from the suggestions instead of googeling the python3 replacement for `:pyf` which they might not be familiar with.

EDIT: picking reviewers according to https://llvm.org/docs/Phabricator.html#finding-potential-reviewers

Reviewers: klimek, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: ilya-biryukov, cfe-commits, llvm-commits, ychen

Patch By: pseyfert

Tags: #clang-tools-extra, #llvm, #clang

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

Revert "test commit"

This reverts commit b0a03f29d9a2d316d6be99e6a4825114f240c0b2.

Revert "test commit"

This reverts commit 3ffce13f8c7ecb21c5729aa358f1f9fc008bbea2.

Revert "Revert "Revert "[clang] Report sanitizer blacklist as a dependency in cc1"""

This reverts commit 3182027282c59c51d5080d83365917fccd695854.

Revert "Revert "[clang] Report sanitizer blacklist as a dependency in cc1""

This reverts commit 6b45e1bc11e91ea7b57a6ab1c19461a86dba33f8.

test commit

test commit

Revert "[clang] Report sanitizer blacklist as a dependency in cc1"

This reverts commit 03b84e4f6d0e1c04f22d69cc445f36e1f713beb4.

This breaks dfsan tests with a linking failure, in for example this build:

  http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24312

Reverting this patch locally makes those tests succeed.

Revert "[compiler-rt] Fix tests after 03b84e4f6d0"

This reverts commit bdeb2724f0aa9c518f94d998d24d8620a1e88727.

(Reverting 03b84e4f6d0, so this must come out as well)

Reland: [TII] Use optional destination and source pair as a return value; NFC

Refactor usage of isCopyInstrImpl, isCopyInstr and isAddImmediate methods
to return optional machine operand pair of destination and source
registers.

Patch by Nikola Prica

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

[lldb] Make Target* a Target& in CommandObjectExpression::DoExecute REPL logic

Subscribers: JDevlieghere, lldb-commits

Tags: #lldb

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

[lldb][NFC] Refactor some IsClangType checks in ClangASTContext

Summary:
All type in these functions need be valid and Clang types, so
we might as well replace these checks with IsClangType.

Also lets IsClangType explicitly check for validity instead of
assuming that the TypeSystem is a nullptr.

Subscribers: abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

[cmake] Enable thin lto cache when building with lld-link

This was enabled for other platforms. Added option for Windows/lld-link.

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

Revert d91ed80 "[codeview] Reference types in type parent scopes"

This triggered asserts in the Chromium build, see https://crbug.com/1022729 for
details and reproducer.

> Without this change, when a nested tag type of any kind (enum, class,
> struct, union) is used as a variable type, it is emitted without
> emitting the parent type. In CodeView, parent types point to their inner
> types, and inner types do not point back to their parents. We already
> walk over all of the parent scopes to build the fully qualified name.
> This change simply requests their type indices as we go along to enusre
> they are all emitted.
>
> Fixes PR43905
>
> Reviewers: akhuang, amccarth
>
> Differential Revision: https://reviews.llvm.org/D69924

[RAGreedy] Enable -consider-local-interval-cost for AArch64

Summary:
The greedy register allocator occasionally decides to insert a large number of
unnecessary copies, see below for an example.  The -consider-local-interval-cost
option (which X86 already enables by default) fixes this.  We enable this option
for AArch64 only after receiving feedback that this change is not beneficial for
PowerPC.

We evaluated the impact of this change on compile time, code size and
performance benchmarks.

This option has a small impact on compile time, measured on CTMark. A 0.1%
geomean regression on -O1 and -O2, and 0.2% geomean for -O3, with at most 0.5%
on individual benchmarks.

The effect on both code size and performance on AArch64 for the LLVM test suite
is nil on the geomean with individual outliers (ignoring short exec_times)
between:

                 best     worst
  size..text     -3.3%    +0.0%
  exec_time      -5.8%    +2.3%

On SPEC CPU® 2017 (compiled for AArch64) there is a minor reduction (-0.2% at
most) in code size on some benchmarks, with a tiny movement (-0.01%) on the
geomean.  Neither intrate nor fprate show any change in performance.

This patch makes the following changes.

- For the AArch64 target, enableAdvancedRASplitCost() now returns true.

- Ensures that -consider-local-interval-cost=false can disable the new
  behaviour if necessary.

This matrix multiply example:

   $ cat test.c
   long A[8][8];
   long B[8][8];
   long C[8][8];

   void run_test() {
     for (int k = 0; k < 8; k++) {
       for (int i = 0; i < 8; i++) {
 for (int j = 0; j < 8; j++) {
   C[i][j] += A[i][k] * B[k][j];
 }
       }
     }
   }

results in the following generated code on AArch64:

  $ clang --target=aarch64-arm-none-eabi -O3 -S test.c -o -
  [...]
                                        // %for.cond1.preheader
                                        // =>This Inner Loop Header: Depth=1
        add     x14, x11, x9
        str     q0, [sp, #16]           // 16-byte Folded Spill
        ldr     q0, [x14]
        mov     v2.16b, v15.16b
        mov     v15.16b, v14.16b
        mov     v14.16b, v13.16b
        mov     v13.16b, v12.16b
        mov     v12.16b, v11.16b
        mov     v11.16b, v10.16b
        mov     v10.16b, v9.16b
        mov     v9.16b, v8.16b
        mov     v8.16b, v31.16b
        mov     v31.16b, v30.16b
        mov     v30.16b, v29.16b
        mov     v29.16b, v28.16b
        mov     v28.16b, v27.16b
        mov     v27.16b, v26.16b
        mov     v26.16b, v25.16b
        mov     v25.16b, v24.16b
        mov     v24.16b, v23.16b
        mov     v23.16b, v22.16b
        mov     v22.16b, v21.16b
        mov     v21.16b, v20.16b
        mov     v20.16b, v19.16b
        mov     v19.16b, v18.16b
        mov     v18.16b, v17.16b
        mov     v17.16b, v16.16b
        mov     v16.16b, v7.16b
        mov     v7.16b, v6.16b
        mov     v6.16b, v5.16b
        mov     v5.16b, v4.16b
        mov     v4.16b, v3.16b
        mov     v3.16b, v1.16b
        mov     x12, v0.d[1]
        fmov    x15, d0
        ldp     q1, q0, [x14, #16]
        ldur    x1, [x10, #-256]
        ldur    x2, [x10, #-192]
        add     x9, x9, #64             // =64
        mov     x13, v1.d[1]
        fmov    x16, d1
        ldr     q1, [x14, #48]
        mul     x3, x15, x1
        mov     x14, v0.d[1]
        fmov    x17, d0
        mov     x18, v1.d[1]
        fmov    x0, d1
        mov     v1.16b, v3.16b
        mov     v3.16b, v4.16b
        mov     v4.16b, v5.16b
        mov     v5.16b, v6.16b
        mov     v6.16b, v7.16b
        mov     v7.16b, v16.16b
        mov     v16.16b, v17.16b
        mov     v17.16b, v18.16b
        mov     v18.16b, v19.16b
        mov     v19.16b, v20.16b
        mov     v20.16b, v21.16b
        mov     v21.16b, v22.16b
        mov     v22.16b, v23.16b
        mov     v23.16b, v24.16b
        mov     v24.16b, v25.16b
        mov     v25.16b, v26.16b
        mov     v26.16b, v27.16b
        mov     v27.16b, v28.16b
        mov     v28.16b, v29.16b
        mov     v29.16b, v30.16b
        mov     v30.16b, v31.16b
        mov     v31.16b, v8.16b
        mov     v8.16b, v9.16b
        mov     v9.16b, v10.16b
        mov     v10.16b, v11.16b
        mov     v11.16b, v12.16b
        mov     v12.16b, v13.16b
        mov     v13.16b, v14.16b
        mov     v14.16b, v15.16b
        mov     v15.16b, v2.16b
        ldr     q2, [sp]                // 16-byte Folded Reload
        fmov    d0, x3
        mul     x3, x12, x1
  [...]

With -consider-local-interval-cost the same section of code results in the
following:

  $ clang --target=aarch64-arm-none-eabi -mllvm -consider-local-interval-cost -O3 -S test.c -o -
  [...]
  .LBB0_1:                              // %for.cond1.preheader
                                        // =>This Inner Loop Header: Depth=1
        add     x14, x11, x9
        ldp     q0, q1, [x14]
        ldur    x1, [x10, #-256]
        ldur    x2, [x10, #-192]
        add     x9, x9, #64             // =64
        mov     x12, v0.d[1]
        fmov    x15, d0
        mov     x13, v1.d[1]
        fmov    x16, d1
        ldp     q0, q1, [x14, #32]
        mul     x3, x15, x1
        cmp     x9, #512                // =512
        mov     x14, v0.d[1]
        fmov    x17, d0
        fmov    d0, x3
        mul     x3, x12, x1
  [...]

Reviewers: SjoerdMeijer, samparker, dmgreen, qcolombet

Reviewed By: dmgreen

Subscribers: ZhangKang, jsji, wuzish, ppc-slack, lkail, steven.zhang, MatzeB, qcolombet, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

Keep symbols passed by -init and -fini

Previously, symbols passed by -init and -fini look as if they are
not referenced by anyone, and the LTO might eliminate them.
This patch fixes the issue.

Fixes a bug reported in https://bugs.llvm.org/show_bug.cgi?id=43927

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

[RISCV] Fix evaluation of %pcrel_lo

The following testcase

  function:
  .Lpcrel_label1:
   auipc a0, %pcrel_hi(other_function)
   addi a1, a0, %pcrel_lo(.Lpcrel_label1)
   .p2align 2          # Causes a new fragment to be emitted

   .type other_function,@function
  other_function:
   ret

exposes an odd behaviour in which only the %pcrel_hi relocation is
evaluated but not the %pcrel_lo.

  $ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump  -d -r -

  <stdin>: file format ELF64-riscv

  Disassembly of section .text:
  0000000000000000 function:
         0: 17 05 00 00 auipc a0, 0
         4: 93 05 05 00 mv a1, a0
   0000000000000004:  R_RISCV_PCREL_LO12_I other_function+4

  0000000000000008 other_function:
         8: 67 80 00 00 ret

The reason seems to be that in RISCVAsmBackend::shouldForceRelocation we
only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we
consider the section. This usually works but there are cases where the
section may still be the same but the fragment may be another one. In
that case we end forcing a %pcrel_lo relocation without any %pcrel_hi.

This patch makes RISCVAsmBackend::shouldForceRelocation use the section,
if any, to determine if the relocation must be forced or not.

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

[Analyzer] Checker for Debugging Iterator Checkers

For white-box testing correct container and iterator modelling it is essential
to access the internal data structures stored for container and iterators. This
patch introduces a simple debug checkers called debug.IteratorDebugging to
achieve this.

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

[NFC][IndVarS] Adjust a comment

(test commit)

[CR] ConstantRange::sshl_sat(): check sigdness of the min/max, not ranges

This was pointed out in review,
but forgot to stage this change into the commit itself..

[ConstantRange] Add `ushl_sat()`/`sshl_sat()` methods.

Summary:
To be used in `ConstantRange::shlWithNoOverflow()`,
may in future be useful for when saturating shift/mul ops are added.

Unlike `ConstantRange::shl()`, these are precise.

Reviewers: nikic, spatel, reames

Reviewed By: nikic

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

[BPF] turn on -mattr=+alu32 for cpu version v3 and later

-mattr=+alu32 has shown good performance vs. without this attribute.
Based on discussion at
  https://lore.kernel.org/bpf/1ec37838-966f-ec0b-5223-ca9b6eb0860d@fb.com/T/#t
cpu version v3 should support -mattr=+alu32.
This patch enabled alu32 if cpu version is v3, either specified by user
or probed by the llvm.

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

Reordering KextImageInfo::LoadImageUsingMemoryModule
so we only call ModulesDidLoad at the end of the method
after the new module has been added to the target and
the sections have all been adjusted to their actual
load addresses.  Solves a problem where an operating
system plugin in the kernel could be loaded multiple
times; the first before the binary had even been
added to the target.

<rdar://problem/50523558>

[PowerPC][Altivec] Fix offsets for vec_xl and vec_xst

As we currently have it implemented in altivec.h, the offsets for these two
intrinsics are element offsets. The documentation in the ABI (as well as the
implementation in both XL and GCC) states that these should be byte offsets.

Differential revision: https://reviews.llvm.org/D63636

[PowerPC][Altivec] Emit correct builtin for single precision vec_all_ne

We currently emit a double precision comparison instruction for this, whereas we
need to emit the single precision version.

Differential revision: https://reviews.llvm.org/D64024

[PowerPC] Option for enabling absolute jumptables with command line

This option allows the user to specify the use of absolute jumptables instead
of relative which is the default on most PPC subtargets.

Patch by Kamauu Bridgeman

Differential revision: https://reviews.llvm.org/D69108

[creduce] Fixed a typo in the error message we're looking for.

[analyzer] Add test cases for the unsupported C++ constructor modeling.

Namely, for the following items:
- Handle constructors within new[];
- Handle constructors for default arguments.

Update the open projects page with a link to the newly added tests
and more hints for potential contributors.

Patch by Daniel Krupp!

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

[analyzer] PR41729: CStringChecker: Improve strlcat and strlcpy modeling.

- Fix false positive reports of strlcat.
- The return value of strlcat and strlcpy is now correctly calculated.
- The resulting string length of strlcat and strlcpy is now correctly
  calculated.

Patch by Daniel Krupp!

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

[llvm/test] Update test comments

[MC] Delete defaulted constructor llvm::AsmCond::AsmCond

[InstCombine] Don't transform bitcasts between x86_mmx and v1i64 into insertelement/extractelement

x86_mmx is conceptually a vector already. Don't introduce an extra conversion between it and scalar i64.

I'm using VectorType::isValidElementType which checks for floating point, integer, and pointers to hopefully make this more readable than just blacklisting x86_mmx.

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

[InstCombine] auto-generate complete checks; NFC

Modernize TestWeakSymbols Makefile

[SEH] Defer checking filter expression types until instantiaton

While here, wordsmith the error a bit. Now clang says:
  error: filter expression has non-integral type 'Foo'

Fixes PR43779

Reviewers: amccarth

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

Correctly update isSignalFrame when unwinding the stack via dwarf.

A "signal frame" is a function or block of code where execution arrives via a signal or interrupt, rather than via a normal call instruction. In fact, a particular instruction is interrupted by the signal and needs to be restarted. Therefore, when the signal handler is complete, execution needs to return to the interrupted instruction, rather than the instruction immediately following the call instruction, as in a normal call.

Stack unwinders need to know this to correctly unwind signal frames. Dwarf handily provides an "S" in the CIE augmentation string to describe this case, and the libunwind API provides various functions to for unwinders to determine it,.

The llvm libunwind implementation correctly sets it's internal variable "isSignalFrame" when initializing an unwind context. However, upon stepping up the stack, the current implementation correctly reads the augmentation string and sets it in the CIE info (which it then discards), libunwind doesn't update it's internal unwind context data structure.

This change fixes that, and provides compatibility with both the canonical libunwind and the libgcc implementation.

Reviewers: jfb

Subscribers: christof, libcxx-commits

Tags: #libc

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

gn build: Merge 25ee861372f

[debugify] Move the Debugify pass from tools/opt to lib/Transform/Utils

Summary:
I need to make use of this pass from a driver program that isn't opt.
Therefore this patch moves this pass into the LLVM library so that it is
available for use elsewhere.

There was one function I kept in tools/opt which is exportDebugifyStats()
this is because it's serializing the statistics into a human readable
format and this seemed more in keeping with opt than a library function

Reviewers: vsk, aprantl

Subscribers: mgorny, hiraditya, llvm-commits

Tags: #llvm

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

[compiler-rt] Fix tests after 03b84e4f6d0

Fallout from:
[clang] Report sanitizer blacklist as a dependency in cc1

Default blacklists are now passed via -fsanitize-system-blacklist from driver to cc1.

BreakpointDummyOptionGroup was using g_breakpoint_modify_options rather than g_breakpoint_dummy_options
causing the -D option for breakpoint set command to be incorrectly parsed.

Patch by Martin Svensson.

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

[clang] Report sanitizer blacklist as a dependency in cc1

Previously these were reported from the driver which blocked clang-scan-deps from getting the full set of dependencies from cc1 commands.

Also the default sanitizer blacklist that is added in driver was never reported as a dependency. I introduced -fsanitize-system-blacklist cc1 option to keep track of which blacklists were user-specified and which were added by driver and clang -MD now also reports system blacklists as dependencies.

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

Revert "[MachineVerifier] Improve verification of live-in lists.

This reverts commit b7b170c to give the author more time to address failing tests on the expensive checks buildbots.

[codeview] Reference types in type parent scopes

Without this change, when a nested tag type of any kind (enum, class,
struct, union) is used as a variable type, it is emitted without
emitting the parent type. In CodeView, parent types point to their inner
types, and inner types do not point back to their parents. We already
walk over all of the parent scopes to build the fully qualified name.
This change simply requests their type indices as we go along to enusre
they are all emitted.

Fixes PR43905

Reviewers: akhuang, amccarth

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

[Diagnostics] Teach -Wnull-dereference about address_space attribute

Summary:
Clang should not warn for:

> test.c:2:12: warning: indirection of non-volatile null pointer will be deleted,
>       not trap [-Wnull-dereference]
>     return *(int __attribute__((address_space(256))) *) 0;
>            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Solves PR42292.

Reviewers: aaron.ballman, rsmith

Reviewed By: aaron.ballman

Subscribers: cfe-commits

Tags: #clang

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

[CodeGenModule] Group blocks runtime globals together, NFC

[lldb] Improve assert in GDBRemoteCommunicationReplayServer

While investigating an issue where a different packet was sent during
replay I noticed how annoying it is that the existing assert doesn't
specify what packet is actually different. It's printed to the log, but
enabling logging has the potential to change LLDB's behavior. The same
is true when debugging LLDB while it's replaying the reproducer.

I replaced the assert with a printf of the unexpected packet followed by
a fatal_error wrapped in ifndef NDEBUG. The behavior is the same as the
previous assert, just with more/better context.

[InstCombine] Add test cases to show bad canonicalization of bitcasts between x86_mmx and <1 x i64>.

As the test cases show, we end up with an insert/extract and a
bitcast to/from i64. x86_mmx is for some purposes conceptually a
vector. We shouldn't be adding scalar conversions around it.

Since _m64 is defined as <1 x i64> and intrinsics use x86_mmx
as their input/output these extra scalar operations prevent
the X86 backend from generating good code especially on 32-bit
targets where i64 gets split.

[Sema] Fixes a crash with a templated destructor

The issue was introduced by D33189 which fixed PR33189.

Fixes PR38671: "destructor cannot be declared as a template" leads to segfault in Sema::LookupSpecialMember

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

[clang] Add -fdebug-default-version for specifying the default DWARF version

This flag decouples specifying the DWARF version from enabling/disabling
DWARF in general (or the gN level - gmlt/limited/standalone, etc) while
still allowing existing -gdwarf-N flags to override this default.

Patch by Caroline Tice!

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

Wrong debug info generated at -O2 (-O0 is correct)

Instcombiner pass was erasing trivially dead instruction without updating dependent llvm.dbg.value.
which was not showing programmer current state of variables while debugging.
As a part of this fix I did following,
Iterate throught all the users (llvm.dbg) of a instruction which is trivially dead and set each if them undef, Before deleting the instruction.
Now user will see optimized out, when try to print those variables.
This fixes
https://bugs.llvm.org/show_bug.cgi?id=43893

This is my first fix to llvm.

Patch by kamlesh kumar!

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

crashlog.py: Improve regular expressions

This is yet another change to the regular expressions in crashlog.py
that fix a few edge cases, and attempt to improve the readability
quite a bit in the process. My last change to support spaces in
filenames introduced a bug that caused the version/archspec field to
be parsed as part of the image name.

For example, in "0x1111111 - 0x22222 +MyApp Pro arm64 <01234>", the
name of the image was recognized as "MyApp Pro arm64" instead of
"MyApp Pro" with a "version" of arm64.

The bugfix makes the space following an optional field mandatory
*inside* the optional group.

rdar://problem/56883435

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

Revert "[Sema] Suppress -Wchar-subscripts if the index is a literal char"

This reverts commit 7adab7719e55e1b29bfd521dcc73f202139e8f41.

FDRRecords - fix uninitialized variable warnings. NFCI.

ImutAVLTree::validateTree - fix null dereference typo warning. NFCI.

Noticed by static analyzer.

canFoldMergeOpcode returns a bool result not an unsigned. NFCI.