Summary:
This change updates the lit.cfg file to use llvm_config when it is available, but when it is not, it directly modifies the config object. This makes it possible to run the lit tests standalone without having built llvm (as long as the correct binaries are present in the path such as FileCheck and not).

Because the lit tests don't take a hard dependency on llvm_config, some features such as system-windows have to have definitions in lit's cfg file as well. This is a potential issue as the os features sometimes change names (for example, we went from windows to system-windows, etc.). This can cause drift between lit's tests and the rest of the llvm tests.

Reviewers: probinson, mgorny

Reviewed By: mgorny

Subscribers: delcypher, llvm-commits, asmith

Tags: #llvm

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

llvm-svn: 367730

The tool used to stop execution if there was an error in the mapping
phase. It will now show the error but continue with the files that were
mapped correctly if the flag is true.

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

llvm-svn: 367729

Mismatched preprocessor, I'll fix in a follow-up.

llvm-svn: 367728

Reviewers: rnk, lebedev.ri

Subscribers: hiraditya, jkorous, dexonsmith, lebedev.ri, llvm-commits

Tags: #llvm

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

llvm-svn: 367727

Summary:
The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang.

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

llvm-svn: 367726

Modifying other AbstractAttributes to use Liveness AA and skip dead instructions.

Reviewers: jdoerfert, uenoku

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 367725

Previously, debuginfo types are annotated to
IR builtin preserve_struct_access_index() and
preserve_union_access_index(), but not
preserve_array_access_index(). The debug info
is useful to identify the root type name which
later will be used for type comparison.

For user access without explicit type conversions,
the previous scheme works as we can ignore intermediate
compiler generated type conversions (e.g., from union types to
union members) and still generate correct access index string.

The issue comes with user explicit type conversions, e.g.,
converting an array to a structure like below:
  struct t { int a; char b[40]; };
  struct p { int c; int d; };
  struct t *var = ...;
  ... __builtin_preserve_access_index(&(((struct p *)&(var->b[0]))->d)) ...
Although BPF backend can derive the type of &(var->b[0]),
explicit type annotation make checking more consistent
and less error prone.

Another benefit is for multiple dimension array handling.
For example,
  struct p { int c; int d; } g[8][9][10];
  ... __builtin_preserve_access_index(&g[2][3][4].d) ...
It would be possible to calculate the number of "struct p"'s
before accessing its member "d" if array debug info is
available as it contains each dimension range.

This patch enables to annotate IR builtin preserve_array_access_index()
with proper debuginfo type. The unit test case and language reference
is updated as well.

Signed-off-by: Yonghong Song <yhs@fb.com>

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

llvm-svn: 367724

These cases can come up when the extending loads combiner doesn't combine a
zext(load) to a zextload op, due to some other operation being in between, which
then gets simplified at a later stage.

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

llvm-svn: 367723

llvm-svn: 367722

[TargetLowering] SimplifyMultipleUseDemandedBits - don't assume INSERT_VECTOR_ELT value type is simple.

Noticed by inspection - this was copied from the X86 target equivalent where we can assume its legal/simple.

llvm-svn: 367721

Summary:
As part of this, define DenseMapInfo for MCRegister (and Register while I'm at it)

Depends on D65599

Reviewers: arsenm

Subscribers: MatzeB, qcolombet, jvesely, wdng, nhaehnle, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367719

This really should have been part of 366765.  For some reason, I forgot to handle the corresponding load side, and the readable test cases (using deopt vs statepoints) turned out to be overly reduced.  Oops.

As seen in the test change, the problem was that we were using a load with alignment expectations rather than the unaligned variant when the stack alignment was less than that prefered type alignment.

llvm-svn: 367718

llvm-svn: 367717

llvm-svn: 367716

This adds support for generating all the loads or stores for a constant mask into a single basic block with no conditionals.

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

llvm-svn: 367715

llvm-svn: 367714

Test on ppc64le passed.
This fix https://bugs.llvm.org/show_bug.cgi?id=42702

llvm-svn: 367713

libObject does not apply the Exported flag to symbols in COFF object files,
which can lead to assertions when the symbol flags initially derived from
IR added to the JIT clash with the flags seen by the JIT linker. Both
RTDyldObjectLinkingLayer and ObjectLinkingLayer have a workaround for this:
they can be told to override the flags seen by the linker with the flags
attached to the materialization responsibility object that was passed down
to the linker. This patch modifies LLJIT's setup code to enable this override
by default on platforms where COFF is the default object format.

llvm-svn: 367712

Summary:
Register can cast to MCRegister and we may want to consider asserting
!isValid() || isPhysical() when expensive checks are on.

Depends on D65554

Reviewers: arsenm

Subscribers: wdng, llvm-commits

Tags: #llvm

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

llvm-svn: 367711

This reverses a questionable IR canonicalization when a truncate
is free:

sra (add (shl X, N1C), AddC), N1C -->
sext (add (trunc X to (width - N1C)), AddC')

https://rise4fun.com/Alive/slRC

More details in PR42644:
https://bugs.llvm.org/show_bug.cgi?id=42644

I limited this to pre-legalization for code simplicity because that
should be enough to reverse the IR patterns. I don't have any
evidence (no regression test diffs) that we need to try this later.

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

llvm-svn: 367710

Summary:
question-mark is not a BRE special character.

POSIX.1-2017 XBD Section 9.3.2 indicates that the interpretation of `\?`
as used by rC366282 is undefined. This patch uses an ERE instead.

Reviewers: rnk, daltenty, xingxue, jasonliu

Reviewed By: rnk

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 367709

This was issued in Objective-C 1 mode, but we not longer support that, so this
is just unreachable.

llvm-svn: 367708

Temporarily Revert "Changing representation of cv_def_range directives in Codeview debug info assembly format for better readability"

This is breaking bots and the author asked me to revert.

This reverts commit 367704.

llvm-svn: 367707

The absolute form is an error when targeting Darwin.

llvm-svn: 367706

[sanitizer_common][tests] Fix SanitizerCommon-Unit :: ./Sanitizer-*-Test/SanitizerCommon.PthreadDestructorIterations on Solaris

SanitizerCommon.PthreadDestructorIterations currently FAILs on Solaris:

  [ RUN      ] SanitizerCommon.PthreadDestructorIterations
  /vol/llvm/src/compiler-rt/local/lib/sanitizer_common/tests/sanitizer_posix_test.cc:58: Failure
  Value of: destructor_executed
    Actual: true
  Expected: false
  [  FAILED  ] SanitizerCommon.PthreadDestructorIterations (1 ms)

It turns out that destructor is called 4 times after the first call to SpawnThread, but
5 times after the second.  While PTHREAD_DESTRUCTOR_ITERATIONS is 4 in
<limits.h>, the Solaris pthread_key_create(3C) man page documents

  If, after all the destructors have been called for all keys  with  non-
  null  values,  there  are  still  some  keys  with non-null values, the
  process will be repeated. POSIX requires that this process be  executed
  at   least   PTHREAD_DESTRUCTOR_ITERATIONS  times.  Solaris  calls  the
  destructors repeatedly until all values with associated destructors are
  NULL. Destructors that set new values can cause an infinite loop.

The patch adjusts the test case to allow for this.

Tested on x86_64-pc-solaris2.11.

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

llvm-svn: 367705

Changing representation of cv_def_range directives in Codeview debug info assembly format for better readability

llvm-svn: 367704

Summary:
If the CallCounts change after an iteration of the DevirtSCCRepeatedPass, this is not reflected in the local CallCounts structure triggering the assertion checking the before/after sizes.
Since it is valid for the size to change and this only uses the CallCounts for the devirtualizing heuristic, keep a <Function*, CallCount> map instead, and make the devirtualizing decision using the counts for the functions that exist both before and after the pass.

Resolves PR42726.

Reviewers: chandlerc

Subscribers: mehdi_amini, jlebar, sanjoy.google, llvm-commits

Tags: #llvm

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

llvm-svn: 367703

It was reported (https://reviews.llvm.org/D65273#1612246)
that this test fails if the compilation directory contain
a "debug_" substring.

This should fix it.

llvm-svn: 367702

Summary: We have been seeing increased reports of performance issue around large project and formatting std::function variables especially in functions signatures in back traces. There are some possible fixes but exploring those fixes may take time and it is better to temporarily disable the formatter due to its impact and re-enable it once we have a fix.

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

llvm-svn: 367701

Add an equivalent ComplexRendererFns function for SelectNegArithImmed. This
allows us to select immediate adds of -1 by turning them into subtracts.

Update select-binop.mir to show that the pattern works.

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

llvm-svn: 367700

Summary:
Since the for loop iterates over BB's predecessors, the branch conditions found must have BB as one of the successors.
For an unconditional branch the successor must be BB, added `assert`.
For a conditional branch, one of the two successors must be BB, simplify `else if` to `else` and `assert`.
Sink common instructions outside the if/else block.

Reviewers: sanjoy.google

Subscribers: jlebar, llvm-commits

Tags: #llvm

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

llvm-svn: 367699

llvm-svn: 367698

llvm-svn: 367697

This fixes a crash in the case where the type info object is an alias
pointing to a non-zero offset within a global or is otherwise unanalyzable
by the stripPointerCasts() function. Looking through the alias is not the
right thing to do anyway for similar reasons as D65118.

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

llvm-svn: 367696

As discussed in PR42696:
https://bugs.llvm.org/show_bug.cgi?id=42696
...but won't help that case yet.

We have an odd situation where a select operand equivalence fold was
implemented in InstSimplify when it could have been done more generally
in InstCombine if we allow dropping of {nsw,nuw,exact} from a binop operand.

Here's an example:
https://rise4fun.com/Alive/Xplr

  %cmp = icmp eq i32 %x, 2147483647
  %add = add nsw i32 %x, 1
  %sel = select i1 %cmp, i32 -2147483648, i32 %add
  =>
  %sel = add i32 %x, 1

I've left the InstSimplify code in place for now, but my guess is that we'd
prefer to remove that as a follow-up to save on code duplication and
compile-time.

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

llvm-svn: 367695

Summary:
Since clang-tidy supports use of the static analyzer there
should be documentation of how to invoke the static analyzer
checks.

Reviewers: JonasToth, aaron.ballman, NoQ, Szelethus

Reviewed By: aaron.ballman

Subscribers: nickdesaulniers, lebedev.ri, jfb, NoQ, Eugene.Zelenko, xazax.hun, baloghadamsoftware, a.sidorin, Szelethus, donat.nagy, dkrupp, cfe-commits

Tags: #clang

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

llvm-svn: 367694

Previously, if a directory contained only other sub-directories, one
of which was being removed, git llvm would delete the parent and all
its subdirs, even though only one should've been deleted.

This error occurred in r366590, where the commit attempted to remove
lldb/packages/Python/lldbsuite/test/tools/lldb-mi, but git-llvm
erroneously removed the entire contents of
lldb/packages/Python/lldbsuite/test/tools.

This happened because "git apply" automatically removes empty
directories locally, and the absence of a local directory was
previously taken as an indication to call 'svn rm' on that
directory. However, an empty local directory does not necessarily
indicate that the directory is truly empty.

Fix that by removing directories only when they're empty on the git
side.

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

llvm-svn: 367693

llvm-svn: 367692

Summary:
Update StackFrame::GetSymbolContext to mirror the logic in
RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the
pc decrement when the given frame is a signal trap handler frame or the
parent of one, because the pc may not follow a call in these frames.
Accomplish this by adding a behaves_like_zeroth_frame field to
lldb_private::StackFrame, set to true for the zeroth frame, for
signal handler frames, and for parents of signal handler frames.

Also add logic to propagate the signal handler flag from UnwindPlan to
the FrameType on the RegisterContextLLDB it generates, and factor out a
helper to resolve symbol and address range for an Address now that we
need to invoke it in four places.

Reviewers: jasonmolenda, clayborg, jfb

Reviewed By: jasonmolenda

Subscribers: labath, dexonsmith, lldb-commits

Tags: #lldb

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

llvm-svn: 367691

Summary:
The -Wparentheses warnings are enabled by default in clang but they are under
-Wall in gcc (gcc/c-family/c.opt). Some of the operator precedence warnings are
oftentimes criticized as noise (clang: default; gcc: -Wall). If a warning is
very controversial, it is probably not a good idea to enable it by default.
This patch disables the rather annoying ones:

-Wbitwise-op-parentheses, e.g. i & i | i
-Wlogical-op-parentheses, e.g. i && i || i

After this change:

```
* = enabled by default

-Wall
  -Wparentheses
    -Wlogical-op-parentheses
    -Wlogical-not-parentheses*
    -Wbitwise-op-parentheses
    -Wshift-op-parentheses*
    -Woverloaded-shift-op-parentheses*
    -Wparentheses-equality*
    -Wdangling-else*
```

-Woverloaded-shift-op-parentheses is typically followed by overload
resolution failure. We can instead improve the error message, and
probably delete -Woverloaded-shift-op-parentheses in the future. Keep it
for now because it gives some diagnostics.

Reviewers: akyrtzi, jyknight, rtrieu, rsmith, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 367690