Commit Graph

251652 Commits

Author SHA1 Message Date
Chandler Carruth babd4476b2 [PM] Pull a lambda out of an argument into a named variable to try and
get a little more clarity about the nature of the issue MSVC is having
with this code.

llvm-svn: 291656
2017-01-11 08:23:29 +00:00
Chandler Carruth 80813b157e [PM] Another attempt to satisfy MSVC.
llvm-svn: 291655
2017-01-11 07:53:12 +00:00
Chandler Carruth d3435487bf [PM] Try to appease MSVC by explicitly disambiguating a member name as
a template.

llvm-svn: 291654
2017-01-11 07:37:50 +00:00
Manuel Klimek f38d74e78b Only launch asynchronously if threading is enabled.
llvm-svn: 291653
2017-01-11 07:20:46 +00:00
Dean Michael Berris d6c18657bb [XRay] Define the library for XRay trace logs
Summary:
In this change we move the definition of the log reading routines from
the tools directory in LLVM to {include/llvm,lib}/XRay. We improve the
documentation a little bit for the publicly accessible headers, and
adjust the top-matter. This also leads to some refactoring and cleanup
in the tooling code.

In particular, we do the following:

  - Rename the class from LogReader to Trace, as it better represents
    the logical set of records as opposed to a log.
  - Use file type detection instead of asking the user to say what
    format the input file is. This allows us to keep the interface
    simple and encapsulate the logic of loading the data appropriately.

In future changes we increase the API surface and write dedicated unit
tests for the XRay library.

Depends on D24376.

Reviewers: dblaikie, echristo

Subscribers: mehdi_amini, mgorny, llvm-commits, varno

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

llvm-svn: 291652
2017-01-11 06:39:09 +00:00
Chandler Carruth 410eaeb064 [PM] Rewrite the loop pass manager to use a worklist and augmented run
arguments much like the CGSCC pass manager.

This is a major redesign following the pattern establish for the CGSCC layer to
support updates to the set of loops during the traversal of the loop nest and
to support invalidation of analyses.

An additional significant burden in the loop PM is that so many passes require
access to a large number of function analyses. Manually ensuring these are
cached, available, and preserved has been a long-standing burden in LLVM even
with the help of the automatic scheduling in the old pass manager. And it made
the new pass manager extremely unweildy. With this design, we can package the
common analyses up while in a function pass and make them immediately available
to all the loop passes. While in some cases this is unnecessary, I think the
simplicity afforded is worth it.

This does not (yet) address loop simplified form or LCSSA form, but those are
the next things on my radar and I have a clear plan for them.

While the patch is very large, most of it is either mechanically updating loop
passes to the new API or the new testing for the loop PM. The code for it is
reasonably compact.

I have not yet updated all of the loop passes to correctly leverage the update
mechanisms demonstrated in the unittests. I'll do that in follow-up patches
along with improved FileCheck tests for those passes that ensure things work in
more realistic scenarios. In many cases, there isn't much we can do with these
until the loop simplified form and LCSSA form are in place.

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

llvm-svn: 291651
2017-01-11 06:23:21 +00:00
Craig Topper 7af39837a9 Revert r291645 "[DAGCombiner] Teach DAG combiner to fold (vselect (N0 xor AllOnes), N1, N2) -> (vselect N0, N2, N1). Only do this if the target indicates its vector boolean type is ZeroOrNegativeOneBooleanContent."
Some test appears to be hanging on the build bots.

llvm-svn: 291650
2017-01-11 04:59:25 +00:00
Adam Nemet e2aaf3a35e [LICM] Report failing to hoist conditionally-executed loads
These are interesting again because the user may not be aware that this
is a common reason preventing LICM.

A const is removed from an instruction pointer declaration in order to
pass it to ORE.

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

llvm-svn: 291649
2017-01-11 04:39:49 +00:00
Adam Nemet 81941b3195 [LICM] Report failing to hoist a load with an invariant address
These are interesting because lack of precision in alias information
could be standing in the way of this optimization.

An example is the case in the test suite that I showed in the DevMeeting
talk:

http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/MultiSource/Benchmarks/FreeBench/distray/CMakeFiles/distray.dir/html/_org_test-suite_MultiSource_Benchmarks_FreeBench_distray_distray.c.html#L236

canSinkOrHoistInst is also used from LoopSink, which does not use
opt-remarks so we need to take ORE as an optional argument.

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

llvm-svn: 291648
2017-01-11 04:39:45 +00:00
Adam Nemet 4d6fb400e9 Fix typo in comment
llvm-svn: 291647
2017-01-11 04:39:41 +00:00
Adam Nemet 358433ce1b [LICM] Report successful hoist/sink/promotion
Differential Revision: https://reviews.llvm.org/D27938

llvm-svn: 291646
2017-01-11 04:39:35 +00:00
Craig Topper 577d258569 [DAGCombiner] Teach DAG combiner to fold (vselect (N0 xor AllOnes), N1, N2) -> (vselect N0, N2, N1). Only do this if the target indicates its vector boolean type is ZeroOrNegativeOneBooleanContent.
llvm-svn: 291645
2017-01-11 04:02:23 +00:00
Bruno Cardoso Lopes ba1b5c98ba [Modules] Support #import when entering files with modules
Textual headers and builtins that are #import'd from different
modules should get re-entered when these modules are independent
from each other.

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

rdar://problem/25881934

llvm-svn: 291644
2017-01-11 02:14:51 +00:00
Matt Arsenault e482403e1c DAGCombiner: Add hasOneUse checks to fadd/fma combine
Even with aggressive fusion enabled, this requires duplicating
the fmul, or increases an fadd to another fma which is not an
improvement.

llvm-svn: 291642
2017-01-11 02:02:12 +00:00
Eugene Zelenko c4ad1ce068 [Target] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 291641
2017-01-11 01:45:03 +00:00
Hans Wennborg 6573976f57 Re-commit r289955: [X86] Fold (setcc (cmp (atomic_load_add x, -C) C), COND) to (setcc (LADD x, -C), COND) (PR31367)
This was reverted because it would miscompile code where the cmp had
multiple uses. That was due to a deficiency in the existing code, which
was fixed in r291630 (see the PR for details).

This re-commit includes an extra test for the kind of code that got
miscompiled: @test_sub_1_setcc_jcc.

llvm-svn: 291640
2017-01-11 01:36:57 +00:00
Kuba Mracek 14cabdd2c3 Follow-up for r291277: Add a return to silence GCC's "control reaches end of non-void function" warning.
llvm-svn: 291639
2017-01-11 01:12:53 +00:00
Chandler Carruth 23bae6df12 Teach Polly's standalone build to work now that we include the gmock
component of gtest.

llvm-svn: 291638
2017-01-11 01:07:37 +00:00
Chandler Carruth 290ea508a6 Teach Polly's unittest macro to link LLVMDemangle which LLVMSupport now
depends on...

llvm-svn: 291637
2017-01-11 01:07:35 +00:00
NAKAMURA Takumi b09bec262b tools/llvm-xray: Avoid std::errc::protocol_* to appease mingw, like r285261.
They are oriented from winsock and mingw doesn't import them.

llvm-svn: 291636
2017-01-11 01:06:57 +00:00
Devin Coughlin aac894feba [analyzer] Fix crash in body farm for getter without implicit self.
Fix a crash in body farm when synthesizing a getter for a property
synthesized for a property declared in a protocol on a class extension
that shadows a declaration of the property in a category.

In this case, Sema doesn't fill in the implicit 'self' parameter for the getter
in the category, which leads to a crash when trying to synthesize the getter
for it.

To avoid the crash, skip getter synthesis in body farm if the self parameter is
not filled int.

rdar://problem/29938138

llvm-svn: 291635
2017-01-11 01:02:34 +00:00
Matt Arsenault 8260666d11 InstSimplify: Refactor function to use more switches
llvm-svn: 291634
2017-01-11 00:57:54 +00:00
Zachary Turner c253c70abd Remove unused field.
llvm-svn: 291633
2017-01-11 00:56:53 +00:00
Petr Hosek 777de22120 [CMake][libcxx] Do not rely on the existence of c++abi or unwind targets
There is no guaranteed order in which CMake files for individual
runtimes are invoked and therefore we cannot rely on existence of
targets defined in other runtimes. Use the new HAVE_<name> options
instead in those cases.

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

llvm-svn: 291632
2017-01-11 00:56:10 +00:00
Kuba Mracek e7709560ea [tsan] Implement a 'ignore_noninstrumented_modules' flag to better suppress false positive races
On Darwin, we currently use 'ignore_interceptors_accesses', which is a heavy-weight solution that simply turns of race detection in all interceptors. This was done to suppress false positives coming from system libraries (non-instrumented code), but it also silences a lot of real races. This patch implements an alternative approach that should allow us to enable interceptors and report races coming from them, but only if they are called directly from instrumented code.

The patch matches the caller PC in each interceptors. For non-instrumented code, we call ThreadIgnoreBegin.

The assumption here is that the number of instrumented modules is low. Most likely there's only one (the instrumented main executable) and all the other modules are system libraries (non-instrumented).

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

llvm-svn: 291631
2017-01-11 00:54:26 +00:00
Hans Wennborg 12de693747 [X86] Dont run combineSetCCAtomicArith() when the cmp has multiple uses
We would miscompile the following:

  void g(int);
  int f(volatile long long *p) {
    bool b = __atomic_fetch_add(p, 1, __ATOMIC_SEQ_CST) < 0;
    g(b ? 12 : 34);
    return b ? 56 : 78;
  }

into

  pushq   %rax
  lock            incq    (%rdi)
  movl    $12, %eax
  movl    $34, %edi
  cmovlel %eax, %edi
  callq   g(int)
  testq   %rax, %rax   <---- Bad.
  movl    $56, %ecx
  movl    $78, %eax
  cmovsl  %ecx, %eax
  popq    %rcx
  retq

because the code failed to take into account that the cmp has multiple
uses, replaced one of them, and left the other one comparing garbage.

llvm-svn: 291630
2017-01-11 00:49:54 +00:00
Quentin Colombet 0b63b31b2e [RegBankSelect] Improve the output of the debug messages.
Add more information about mapping cost and chosen solution.

llvm-svn: 291629
2017-01-11 00:48:41 +00:00
Manman Ren 7f41c4d802 Module: Do not create Implicit ImportDecl for module X if we
are building an implemenation of module X.

This fixes a regression caused by r280409.
rdar://problem/29930553

llvm-svn: 291628
2017-01-11 00:48:19 +00:00
Zachary Turner a9054ddd9c [CodeView/PDB] Rename a bunch of files.
We were starting to get some name clashes between llvm-pdbdump
and the common CodeView framework, so I took this opportunity
to rename a bunch of files to more accurately describe their
usage.  This also helps in llvm-pdbdump to distinguish
between different files and whether they are used for pretty
dump mode or raw dump mode.

llvm-svn: 291627
2017-01-11 00:35:43 +00:00
Zachary Turner c640b76db5 [CodeView] Add TypeDatabase class.
This creates a centralized class in which to store type records.
It stores types as an array of entries, which matches the
notion of a type stream being a topologically sorted DAG.
Logic to build up such a database was already being used in
CVTypeDumper, so CVTypeDumper is now updated to to read from
a TypeDatabase which is filled out by an earlier visitor in
the pipeline.

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

llvm-svn: 291626
2017-01-11 00:35:08 +00:00
Zachary Turner 545c4a95e1 Add better documentation for iterator facade subclasses.
llvm-svn: 291625
2017-01-11 00:34:41 +00:00
Matt Arsenault 1e0edbf03c InstSimplify: Eliminate fabs on known positive
llvm-svn: 291624
2017-01-11 00:33:24 +00:00
Chandler Carruth 1b31646465 [gmock] Teach gmock ElementsAre and BeginEndDistanceIs matchers to
handle generic ranges by using std::begin and std::end rather than
requiring things to look exactly like an STL container.

Much of the credit for this goes to Dave Blaikie who helped me figure
out the right incantations.

This will probably be re-designed when I send this to the maintainers of
gmock, so I've instead structured it to change is little as possible
while it is a local patch. That makes it somewhat ugly, but I think a focused
change is better for getting this to work for LLVM today and letting the
upstream maintainers figure out the correct long-term pattern.

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

llvm-svn: 291623
2017-01-11 00:16:03 +00:00
Jan Vesely 0d6cb1caaf AMDGPU/EG,CM: Add fp16 conversion instructions
Differential Revision: https://reviews.llvm.org/D28164

llvm-svn: 291622
2017-01-11 00:12:39 +00:00
Rong Xu acd6360251 Revert "[PGO] Turn off comdat renaming in IR PGO by default"
This patch reverts r291588: [PGO] Turn off comdat renaming in IR PGO by default,
as we are seeing some hash mismatches in our internal tests.

llvm-svn: 291621
2017-01-10 23:54:31 +00:00
Sanjay Patel db0938fd9a [InstCombine] add a wrapper for a common pair of transforms; NFCI
Some of the callers are artificially limiting this transform to integer types;
this should make it easier to incrementally remove that restriction.

llvm-svn: 291620
2017-01-10 23:49:07 +00:00
Florian Hahn 4f9d6d56c0 [loop-unroll] Properly populate LoopInfo for loops cloned in LoopUnrollRuntime.
Summary:
This fixes Transforms/LoopUnroll/runtime-loop3.ll which failed with
EXTENSIVE_DEBUG, because the cloned basic blocks were not added to the
correct sub-loops in LoopUnrollRuntime.cpp.


Reviewers: dexonsmith, mzolotukhin

Subscribers: llvm-commits

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

llvm-svn: 291619
2017-01-10 23:43:35 +00:00
Justin Lebar 7d81813d76 [TM] Restore default TargetOptions in TargetMachine::resetTargetOptions.
Summary:
Previously if you had

 * a function with the fast-math-enabled attr, followed by
 * a function without the fast-math attr,

the second function would inherit the first function's fast-math-ness.

This means that mixing fast-math and non-fast-math functions in a module
was completely broken unless you explicitly annotated every
non-fast-math function with "unsafe-fp-math"="false".  This appears to
have been broken since r176986 (March 2013), when the resetTargetOptions
function was introduced.

This patch tests the correct behavior as best we can.  I don't think I
can test FPDenormalMode and NoTrappingFPMath, because they aren't used
in any backends during function lowering.  Surprisingly, I also can't
find any uses at all of LessPreciseFPMAD affecting generated code.

The NVPTX/fast-math.ll test changes are an expected result of fixing
this bug.  When FMA is disabled, we emit add as "add.rn.f32", which
prevents fma combining.  Before this patch, fast-math was enabled in all
functions following the one which explicitly enabled it on itself, so we
were emitting plain "add.f32" where we should have generated
"add.rn.f32".

Reviewers: mkuper

Subscribers: hfinkel, majnemer, jholewinski, nemanjai, llvm-commits

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

llvm-svn: 291618
2017-01-10 23:43:04 +00:00
Justin Lebar c1e2d97a2c [NVPTX] Add CHECK-LABEL where appropriate to fast-math.ll test.
Also fix up whitespace.

Test-only change.

llvm-svn: 291617
2017-01-10 23:42:46 +00:00
Evandro Menezes 330e1b8945 [AArch64] Consider all vector types for FeatureSlowMisaligned128Store
The original code considered only v2i64 as slow for this feature. This patch
consider all 128-bit long vector types as slow candidates.

In internal tests, extending this feature to all 128-bit vector types
resulted in an overall improvement of 1% on Exynos M1.

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

llvm-svn: 291616
2017-01-10 23:42:21 +00:00
Matt Arsenault 51818c14b3 AMDGPU: Constant fold when immediate is materialized
In future commits these patterns will appear after moveToVALU changes.

llvm-svn: 291615
2017-01-10 23:32:04 +00:00
Florian Hahn fdea2e420c [loop-unroll] Factor out code to update LoopInfo (NFC).
Move the code to update LoopInfo for cloned basic blocks to
addClonedBlockToLoopInfo, as suggested in 
https://reviews.llvm.org/D28482.

llvm-svn: 291614
2017-01-10 23:24:54 +00:00
Reid Kleckner 443423e38a Move the section name from GlobalObject to the LLVMContext
Summary:
Convention wisdom says that bytes in Function are precious, and the
vast, vast majority of globals do not live in special sections. Even
when they do, they tend to live in the same section. Store the section
name on the LLVMContext in a StringSet, and maintain a map from
GlobalObject* to section name like we do for metadata, prefix data, etc.

The fact that we've survived this long wasting at least three pointers
of space in Function suggests that Function bytes are perhaps not as
precious as we once thought. Given that most functions have metadata
attachments when debug info is enabled, we might consider adding a
pointer here to make that access more efficient.

Reviewers: jlebar, dexonsmith, mehdi_amini

Subscribers: mehdi_amini, aprantl, llvm-commits

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

llvm-svn: 291613
2017-01-10 23:23:58 +00:00
Matt Arsenault 3f509042b0 InstCombine: Set operands instead of creating new call
llvm-svn: 291612
2017-01-10 23:17:52 +00:00
Matt Arsenault fdb78f8bae InstCombine: fdiv -x, -y -> fdiv x, y
llvm-svn: 291611
2017-01-10 23:08:54 +00:00
Richard Smith 20d252c4c1 Remove dead code.
llvm-svn: 291610
2017-01-10 23:04:46 +00:00
Kyle Butt df27aa8c89 CodeGen: Allow small copyable blocks to "break" the CFG.
When choosing the best successor for a block, ordinarily we would have preferred
a block that preserves the CFG unless there is a strong probability the other
direction. For small blocks that can be duplicated we now skip that requirement
as well.

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

llvm-svn: 291609
2017-01-10 23:04:30 +00:00
Richard Smith 623270694b Remove a couple of parameters that are always false.
llvm-svn: 291608
2017-01-10 22:59:18 +00:00
Matt Arsenault def496c04b Remove unused CONVERT_RNDSAT intrinsics
llvm-svn: 291607
2017-01-10 22:38:02 +00:00
Chandler Carruth bf6a4e0b39 Add the 'googlemock' component of Google Test to LLVM's unittest libraries.
I have two immediate motivations for adding this:
1) It makes writing expectations in tests *dramatically* easier. A
   quick example that is a taste of what is possible:

     std::vector<int> v = ...;
     EXPECT_THAT(v, UnorderedElementsAre(1, 2, 3));

   This checks that v contains '1', '2', and '3' in some order. There
   are a wealth of other helpful matchers like this. They tend to be
   highly generic and STL-friendly so they will in almost all cases work
   out of the box even on custom LLVM data structures.

   I actually find the matcher syntax substantially easier to read even
   for simple assertions:

     EXPECT_THAT(a, Eq(b));
     EXPECT_THAT(b, Ne(c));

   Both of these make it clear what is being *tested* and what is being
   *expected*. With `EXPECT_EQ` this is implicit (the LHS is expected,
   the RHS is tested) and often confusing. With `EXPECT_NE` it is just
   not clear. Even the failure error messages are superior with the
   matcher based expectations.

2) When testing any kind of generic code, you are continually defining
   dummy types with interfaces and then trying to check that the
   interfaces are manipulated in a particular way. This is actually what
   mocks are *good* for -- testing *interface interactions*. With
   generic code, there is often no "fake" or other object that can be
   used.

   For a concrete example of where this is currently causing significant
   pain, look at the pass manager unittests which are riddled with
   counters incremented when methods are called. All of these could be
   replaced with mocks. The result would be more effective at testing
   the code by having tighter constraints. It would be substantially
   more readable and maintainable when updating the code. And the error
   messages on failure would have substantially more information as
   mocks automatically record stack traces and other information *when
   the API is misused* instead of trying to diagnose it after the fact.

I expect that #1 will be the overwhelming majority of the uses of gmock,
but I think that is sufficient to justify having it. I would actually
like to update the coding standards to encourage the use of matchers
rather than any other form of `EXPECT_...` macros as they are IMO
a strict superset in terms of functionality and readability.

I think that #2 is relatively rarely useful, but there *are* cases where
it is useful. Historically, I think misuse of actual mocking as
described in #2 has led to resistance towards this framework. I am
actually sympathetic to this -- mocking can easily be overused. However
I think this is not a significant concern in LLVM. First and foremost,
LLVM has very careful and rare exposure of abstract interfaces or
dependency injection, which are the most prone to abuse with mocks. So
there are few opportunities to abuse them. Second, a large fraction of
LLVM's unittests are testing *generic code* where mocks actually make
tremendous sense. And gmock is well suited to building interfaces that
exercise generic libraries. Finally, I still think we should be willing
to have testing utilities in tree even if they should be used rarely. We
can use code review to help guide the usage here.

For a longer and more complete discussion of this, see the llvm-dev
thread here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108672.html

The general consensus seems that this is a reasonable direction to start
down, but that doesn't mean we should race ahead and use this
everywhere. I have one test that is blocked on this to land and that was
specifically used as an example. Before widespread adoption, I'm going
to work up some (brief) guidelines as some of these facilities should be
used sparingly and carefully.

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

llvm-svn: 291606
2017-01-10 22:32:26 +00:00