Commit Graph

19118 Commits

Author SHA1 Message Date
Chandler Carruth d9a328437e Fix the header comment of the new pass manager stuff to not claim to be
the legacy stuff. =]

llvm-svn: 194689
2013-11-14 10:55:14 +00:00
Kevin Qin afc8bdfd57 [AArch64 neon] support poly64 and relevant intrinsic functions.
llvm-svn: 194659
2013-11-14 03:27:58 +00:00
Kevin Qin aec95baf1a Implement aarch64 neon instruction class SIMD misc.
llvm-svn: 194656
2013-11-14 02:44:13 +00:00
Nick Kledzik dd34f77cbd Add dyn_cast<> support to YAML I/O's IO class
llvm-svn: 194655
2013-11-14 02:38:07 +00:00
Michael Gottesman fd8aee76eb Added BlockFrequencyInfo::view for displaying the block frequency propagation graph via graphviz.
This is useful for debugging issues in the BlockFrequency implementation since
one can easily visualize where probability mass and other errors occur in the
propagation.

llvm-svn: 194654
2013-11-14 02:27:46 +00:00
Jiangning Liu bb60ccf355 Implement AArch64 NEON instruction set AdvSIMD (table).
llvm-svn: 194648
2013-11-14 01:57:32 +00:00
Nick Kledzik 1e6033ca33 Add simple support for tags in YAML I/O
llvm-svn: 194644
2013-11-14 00:59:59 +00:00
Yuchen Wu 7981f5b86c llvm-cov: Slightly improved error checking.
- readInt() should check all 4 bytes can be read, not just 1.
- In the event of false data in the gcno file, it was possible to index
  into a non-existent index of SmallVector, causing assertion error.

llvm-svn: 194639
2013-11-14 00:38:41 +00:00
Yuchen Wu d738beec44 llvm-cov: Removed StringMap holding GCOVLines.
According to the hazy gcov documentation, it appeared to be technically
possible for lines within a block to belong to different source files.
However, upon further investigation, gcov does not actually support
multiple source files for a single block.

This change removes a level of separation between blocks and lines by
replacing the StringMap of GCOVLines with a SmallVector of ints
representing line numbers. This also means that the GCOVLines class is
no longer needed.

This paves the way for supporting the "-a" option, which will output
block information.

llvm-svn: 194637
2013-11-14 00:32:00 +00:00
Yuchen Wu e28da84c96 llvm-cov: Replaced asserts with proper error handling.
Unified the interface for read functions. They all return a boolean
indicating if the read from file succeeded. Functions that previously
returned the read value now store it into a variable that is passed in
by reference instead. Callers will need to check the return value to
detect if an error occurred.

Also added a new test which ensures that no assertions occur when file
contains invalid data. llvm-cov should return with error code 1 upon
failure.

llvm-svn: 194635
2013-11-14 00:07:15 +00:00
Chad Rosier d3ae5f895e [AArch64] Add support for legacy AArch32 NEON scalar shift by immediate
instructions.  This patch does not include the shift right and accumulate
instructions.  A number of non-overloaded intrinsics have been remove in favor
of their overloaded counterparts.

llvm-svn: 194598
2013-11-13 20:05:37 +00:00
Benjamin Kramer 505d2408a1 Make sure LLVMLoadLibraryPermanently gets an extern "C" symbol.
Otherwise it's impossible to use it. Also don't include C++ headers in
a C header.

llvm-svn: 194581
2013-11-13 15:35:13 +00:00
Rafael Espindola fdc88137f4 Remove AllowQuotesInName and friends from MCAsmInfo.
Accepting quotes is a property of an assembler, not of an object file. For
example, ELF can support any names for sections and symbols, but the gnu
assembler only accepts quotes in some contexts and llvm-mc in a few more.

LLVM should not produce different symbols based on a guess about which assembler
will be reading the code it is printing.

llvm-svn: 194575
2013-11-13 14:01:59 +00:00
Diego Novillo 8d6568b56b SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.

The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.

External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.

The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains.  This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.

To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.

The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.

Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.

This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.

Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.

This patch implements:

- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
  generates branch weight metadata on every branch instructions that
  matches the profiles.
- A text loader class to assist the implementation of
  SampleProfile::loadText().
- Basic unit tests for the pass.

Additionally, the patch uses profile information to compute branch
weights based on instruction samples.

This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:

Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.

Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.

I will adjust this assignment in subsequent patches.

llvm-svn: 194566
2013-11-13 12:22:21 +00:00
Chandler Carruth 3d7fd3daa3 Add another (perhaps better) video for Sean's talk. (Thanks Marshall!)
llvm-svn: 194549
2013-11-13 02:49:38 +00:00
Chandler Carruth ccb190972e Fix a null pointer dereference when copying a null polymorphic pointer.
This bug only bit the C++98 build bots because all of the actual uses
really do move. ;] But not *quite* ready to do the whole C++11 switch
yet, so clean it up. Also add a unit test that catches this immediately.

llvm-svn: 194548
2013-11-13 02:48:20 +00:00
Chandler Carruth a477d2ab57 Give folks a reference to some material on the fundamental design
pattern in use here. Addresses review feedback from Sean (thanks!) and
others.

llvm-svn: 194541
2013-11-13 01:51:36 +00:00
Chandler Carruth 74015a7084 Introduce an AnalysisManager which is like a pass manager but with a lot
more smarts in it. This is where most of the interesting logic that used
to live in the implicit-scheduling-hackery of the old pass manager will
live.

Like the previous commits, note that this is a very early prototype!
I expect substantial changes before this is ready to use.

The core of the design is the following:

- We have an AnalysisManager which can be used across a series of
  passes over a module.
- The code setting up a pass pipeline registers the analyses available
  with the manager.
- Individual transform passes can check than an analysis manager
  provides the analyses they require in order to fail-fast.
- There is *no* implicit registration or scheduling.
- Analysis passes are different from other passes: they produce an
  analysis result that is cached and made available via the analysis
  manager.
- Cached results are invalidated automatically by the pass managers.
- When a transform pass requests an analysis result, either the analysis
  is run to produce the result or a cached result is provided.

There are a few aspects of this design that I *know* will change in
subsequent commits:
- Currently there is no "preservation" system, that needs to be added.
- All of the analysis management should move up to the analysis library.
- The analysis management needs to support at least SCC passes. Maybe
  loop passes. Living in the analysis library will facilitate this.
- Need support for analyses which are *both* module and function passes.
- Need support for pro-actively running module analyses to have cached
  results within a function pass manager.
- Need a clear design for "immutable" passes.
- Need support for requesting cached results when available and not
  re-running the pass even if that would be necessary.
- Need more thorough testing of all of this infrastructure.

There are other aspects that I view as open questions I'm hoping to
resolve as I iterate a bit on the infrastructure, and especially as
I start writing actual passes against this.
- Should we have separate management layers for function, module, and
  SCC analyses? I think "yes", but I'm not yet ready to switch the code.
  Adding SCC support will likely resolve this definitively.
- How should the 'require' functionality work? Should *that* be the only
  way to request results to ensure that passes always require things?
- How should preservation work?
- Probably some other things I'm forgetting. =]

Look forward to more patches in shorter order now that this is in place.

llvm-svn: 194538
2013-11-13 01:12:08 +00:00
Aaron Ballman 4337e97029 Removing llvm::huge_vald and llvm::huge_vall because they are not currently used, and HUGE_VALD does not appear to be supported everywhere anyways.
llvm-svn: 194535
2013-11-13 00:20:43 +00:00
Aaron Ballman 04999041e8 Replacing HUGE_VALF with llvm::huge_valf in order to work around a warning triggered in MSVC 12.
Patch reviewed by Reid Kleckner and Jim Grosbach.

llvm-svn: 194533
2013-11-13 00:15:44 +00:00
Rafael Espindola 6cd1b9aec4 Remove always true flag.
llvm-svn: 194530
2013-11-12 23:27:08 +00:00
Sebastian Pop c62c679c1b delinearization of arrays
llvm-svn: 194527
2013-11-12 22:47:20 +00:00
Sebastian Pop 9f8004fb08 remove virtual methods in SCEVApplyRewriter and SCEVParameterRewriter
llvm-svn: 194526
2013-11-12 22:47:05 +00:00
Justin Bogner b10a520c8f Protect user-supplied runtime library functions in LTO
Add user-supplied C runtime and compiler-rt library functions to
llvm.compiler.used to protect them from premature optimization by
passes like -globalopt and -ipsccp.  Calls to (seemingly unused)
runtime library functions can be added by -instcombine and instruction
lowering.

Patch by Duncan Exon Smith, thanks!

Fixes <rdar://problem/14740087>

llvm-svn: 194514
2013-11-12 21:44:01 +00:00
Weiming Zhao 813432f1ae Export intrinsics:__builtin_arm_{dmb,dsb} to frontend
llvm-svn: 194505
2013-11-12 19:57:43 +00:00
Andrew Trick eb443d7f23 GraphViz CFGPrinter: wrap long lines.
llvm-svn: 194496
2013-11-12 18:06:09 +00:00
Andrew Trick 0926513eb1 whitespace
llvm-svn: 194495
2013-11-12 18:06:06 +00:00
Rafael Espindola e1b88dad8f Revert "Remove unused variable."
This reverts commit r194485.

The variable is unused in some macro instantiations, but not others. We should
probably fix clang to not warn on this.

llvm-svn: 194486
2013-11-12 16:37:31 +00:00
Rafael Espindola 984d3c4587 Remove unused variable.
llvm-svn: 194485
2013-11-12 16:31:59 +00:00
Wan Xiaofei b2c8cdc766 Change data structure to memorize computed result in ScalarEvolution
Replace std::map with SmallVector to memorize the cached result since SCEV usually belongs to little Loop/BB
Linear scan on SmallVector is faster than std::map.

Code reviewer : Andrew Trick.
Test result   : Pass Unit Test & LLVM Test Suite

401.bzip2	0.425721	0.419981	101.37%
403.gcc		24.53855	24.2667		101.12%
429.mcf		0.060847	0.059944	101.51%
433.milc	0.646009	0.636119	101.55%
444.namd	1.383928	1.370614	100.97%
445.gobmk	5.836575	5.800225	100.63%
450.soplex	1.911257	1.895963	100.81%
456.hmmer	1.039565	1.032534	100.68%
458.sjeng	0.897401	0.885567	101.34%
464.h264ref	3.645908	3.577991	101.90%
470.lbm		0.049456	0.048398	102.19%
471.omnetpp	5.638575	5.60435		100.61%
bitmnp01	0.045738	0.045291	100.99%
cjpegv2data	0.304359	0.302833	100.50%
idctrn01	0.046433	0.045763	101.46%
quake2		4.534416	4.4952		100.87%
quake		2.688566	2.659208	101.10%
xcsoar		12.42545	12.30385	100.99%
linpack		0.038739	0.03803		101.86%
matrix01	0.053564	0.0528		101.45%
nbench		0.402867	0.395803	101.78%
tblook01	0.021265	0.021015	101.19%
ttsprk01	0.066384	0.065566	101.25%

llvm-svn: 194459
2013-11-12 09:40:41 +00:00
Arnaud A. de Grandmaison f5f040fa1e CalcSpillWeights: allow overidding the spill weight normalizing function
This will enable the PBQP register allocator to provide its own normalizing function.

No functionnal change.

llvm-svn: 194417
2013-11-11 19:56:14 +00:00
Chad Rosier d3684a0566 [AArch64] The shift right/left and insert immediate builtins expect 3
source operands, a vector, an element to insert, and a shift amount.

llvm-svn: 194406
2013-11-11 19:11:11 +00:00
Arnaud A. de Grandmaison ea3ac1612c CalcSpillWeights: give a better describing name to calculateSpillWeights
Besides, this relates it more obviously to the VirtRegAuxInfo::calculateSpillWeightAndHint.

No functionnal change.

llvm-svn: 194404
2013-11-11 19:04:45 +00:00
Chad Rosier 35575e737c [AArch64] Add support for NEON scalar floating-point convert to fixed-point instructions.
llvm-svn: 194394
2013-11-11 18:04:07 +00:00
Peter Zotov d2cf791ad8 [llvm-c] Remove dead typedef
llvm-svn: 194379
2013-11-11 14:47:01 +00:00
Pete Cooper a8b685cd7b Don't universally enable initialiser lists on GCC. Thanks for catching this Chandler
llvm-svn: 194365
2013-11-11 05:14:42 +00:00
Pete Cooper 020832fb6e Add LLVM_HAS_INITIALIZER_LISTS for upcoming C++11 support. Use it in ArrayRef
llvm-svn: 194362
2013-11-11 03:58:00 +00:00
Arnaud A. de Grandmaison 760c1e0b0a CalculateSpillWeights does not need to be a pass
Based on discussions with Lang Hames and Jakob Stoklund Olesen at the hacker's lab, and in the light of upcoming work on the PBQP register allocator, it was though that CalcSpillWeights does not need to be a pass. This change will enable to customize / tune the spill weight computation depending on the allocator.

Update the documentation style while there.

No functionnal change.

llvm-svn: 194356
2013-11-10 17:46:31 +00:00
Chandler Carruth 90a835d2a0 [PM] Start sketching out the new module and function pass manager.
This is still just a skeleton. I'm trying to pull together the
experimentation I've done into committable chunks, and this is the first
coherent one. Others will follow in hopefully short order that move this
more toward a useful initial implementation. I still expect the design
to continue evolving in small ways as I work through the different
requirements and features needed here though.

Keep in mind, all of this is off by default.

Currently, this mostly exercises the use of a polymorphic smart pointer
and templates to hide the polymorphism for the pass manager from the
pass implementation. The next step will be more significant, adding the
first framework of analysis support.

llvm-svn: 194325
2013-11-09 13:09:08 +00:00
Chandler Carruth 7caea41545 Move the old pass manager infrastructure into a legacy namespace and
give the files a legacy prefix in the right directory. Use forwarding
headers in the old locations to paper over the name change for most
clients during the transitional period.

No functionality changed here! This is just clearing some space to
reduce renaming churn later on with a new system.

Even when the new stuff starts to go in, it is going to be hidden behind
a flag and off-by-default as it is still WIP and under development.

This patch is specifically designed so that very little out-of-tree code
has to change. I'm going to work as hard as I can to keep that the case.
Only direct forward declarations of the PassManager class are impacted
by this change.

llvm-svn: 194324
2013-11-09 12:26:54 +00:00
Filip Pizlo dfc9b586ae This exposes the new calling conventions (WebKit_JS and AnyReg) via the C API by adding them to the enumeration in Core.h.
llvm-svn: 194323
2013-11-09 06:00:03 +00:00
Chandler Carruth 42fabdead0 Switch to allow implicit construction. In many cases, we're wrapping
a derived type and this makes it *much* easier to write this code.

llvm-svn: 194321
2013-11-09 05:55:03 +00:00
Chandler Carruth 64b0556071 Add a polymorphic_ptr<T> smart pointer data type. It's a somewhat silly
unique ownership smart pointer which is *deep* copyable by assuming it
can call a T::clone() method to allocate a copy of the owned data.

This is mostly useful with containers or other collections of uniquely
owned data in C++98 where they *might* copy. With C++11 we can likely
remove this in favor of move-only types and containers wrapped around
those types.

llvm-svn: 194315
2013-11-09 04:06:02 +00:00
NAKAMURA Takumi 5f847c007b include/llvm/CodeGen/PBQP: Update @param(s) in comments. [-Wdocumentation]
llvm-svn: 194314
2013-11-09 03:54:05 +00:00
NAKAMURA Takumi 866975c26c Fix whitespace.
llvm-svn: 194313
2013-11-09 03:53:55 +00:00
Lang Hames fb82630a91 Re-apply r194300 with fixes for warnings.
llvm-svn: 194311
2013-11-09 03:08:56 +00:00
Nick Lewycky 59886d00ec Revert r194300 which broke the build.
llvm-svn: 194308
2013-11-09 02:01:25 +00:00
Juergen Ributzka 87ed906b2e [Stackmap] Materialize the jump address within the patchpoint noop slide.
This patch moves the jump address materialization inside the noop slide. This
enables patching of the materialization itself or its complete removal. This
patch also adds the ability to define scratch registers that can be used safely
by the code called from the patchpoint intrinsic. At least one scratch register
is required, because that one is used for the materialization of the jump
address. This patch depends on D2009.

Differential Revision: http://llvm-reviews.chandlerc.com/D2074

Reviewed by Andy

llvm-svn: 194306
2013-11-09 01:51:33 +00:00
Lang Hames 1662b832d9 Rewrite the PBQP graph data structure.
The new graph structure replaces the node and edge linked lists with vectors.
Free lists (well, free vectors) are used for fast insertion/deletion.

The ultimate aim is to make PBQP graphs cheap to clone. The motivation is that
the PBQP solver destructively consumes input graphs while computing a solution,
forcing the graph to be fully reconstructed for each round of PBQP. This
imposes a high cost on large functions, which often require several rounds of
solving/spilling to find a final register allocation. If we can cheaply clone
the PBQP graph and incrementally update it between rounds then hopefully we can
reduce this cost. Further, once we begin pooling matrix/vector values (future
work), we can cache some PBQP solver metadata and share it between cloned
graphs, allowing the PBQP solver to re-use some of the computation done in
earlier rounds.

For now this is just a data structure update. The allocator and solver still
use the graph the same way as before, fully reconstructing it between each
round. I expect no material change from this update, although it may change
the iteration order of the nodes, causing ties in the solver to break in
different directions, and this could perturb the generated allocations
(hopefully in a completely benign way).

Thanks very much to Arnaud Allard de Grandmaison for encouraging me to get back
to work on this, and for a lot of discussion and many useful PBQP test cases.

llvm-svn: 194300
2013-11-09 00:14:07 +00:00
Juergen Ributzka 9969d3e6e8 [Stackmap] Add AnyReg calling convention support for patchpoint intrinsic.
The idea of the AnyReg Calling Convention is to provide the call arguments in
registers, but not to force them to be placed in a paticular order into a
specified set of registers. Instead it is up tp the register allocator to assign
any register as it sees fit. The same applies to the return value (if
applicable).

Differential Revision: http://llvm-reviews.chandlerc.com/D2009

Reviewed by Andy

llvm-svn: 194293
2013-11-08 23:28:16 +00:00