Commit Graph

17886 Commits

Author SHA1 Message Date
Rafael Espindola
2fa06b171b Add support for having multiple sections with the same name and comdat.
Using this in combination with -ffunction-sections allows LLVM to output a .o
file with mulitple sections named .text. This saves space by avoiding long
unique names of the form .text.<C++ mangled name>.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228980 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-12 23:29:51 +00:00
Hal Finkel
8452d01224 [SDAG] Don't try to use FP_EXTEND/FP_ROUND for int<->fp promotions
The PowerPC backend has long promoted some floating-point vector operations
(such as select) to integer vector operations. Unfortunately, this behavior was
broken by r216555. When using FP_EXTEND/FP_ROUND for promotions, we must check
that both the old and new types are floating-point types. Otherwise, we must
use BITCAST as we did prior to r216555 for everything.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228969 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-12 22:43:52 +00:00
Rafael Espindola
c3c5d7c2d6 On ELF, put PIC jump tables in a non executable section.
Fixes PR22558.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228939 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-12 17:46:49 +00:00
Rafael Espindola
8eeedf74d3 Put each jump table in an independent section if the function is too.
This allows the linker to GC both, fixing pr22557.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228937 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-12 17:16:46 +00:00
Benjamin Kramer
d913d9d2c3 MathExtras: Bring Count(Trailing|Leading)Ones and CountPopulation in line with countTrailingZeros
Update all callers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228930 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-12 15:35:40 +00:00
Ahmed Bougacha
9e9bde9b54 [CodeGen] Don't blindly combine (fp_round (fp_round x)) to (fp_round x).
We used to do this DAG combine, but it's not always correct:
If the first fp_round isn't a value preserving truncation, it might
introduce a tie in the second fp_round, that wouldn't occur in the
single-step fp_round we want to fold to.
In other words, double rounding isn't the same as rounding.

Differential Revision: http://reviews.llvm.org/D7571


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228911 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-12 06:15:29 +00:00
Jonas Paulsson
fc58cf7676 Fix SelectionDAG compile time issue with alias analysis.
Add new token factor node and its users to worklist if alias analysis is
turned on, in DAGCombiner::visitTokenFactor(). Alias analysis may cause
a lot of new token factors to be inserted into the DAG, and they need to
be optimized to avoid significant slow-downs.

Reviewed by Hal Finkel.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228841 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-11 16:10:31 +00:00
Rafael Espindola
831855275d Don't repeat name in comment and clang-format a function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228831 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-11 14:44:17 +00:00
Arnaud A. de Grandmaison
8ee1b65836 [PBQP] Cautiously update edge costs in the solver
The NodeMetadata are maintained in an incremental way. When an edge between
2 nodes has its cost updated, in the course of graph reduction for example,
the NodeMetadata need first to have the old edge cost removed, then the new
edge cost added. Only once the NodeMetadata have been fully updated, it
becomes safe to consider promoting the nodes to the
ConservativelyAllocatable or OptimallyReducible sets. Previously, this
promotion was occuring right after the removing the old cost, and this was
breaking the assumption that a ConservativelyAllocatable should not be
spilled.

This patch also adds asserts to:
 - enforces the invariant that a node's reduction can not be downgraded,
 - only not provably allocatable or optimally reducible nodes can be spilled.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228816 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-11 08:25:36 +00:00
Zachary Turner
c371307e60 Use ADDITIONAL_HEADER_DIRS in all LLVM CMake projects.
This allows IDEs to recognize the entire set of header files for
each of the core LLVM projects.

Differential Revision: http://reviews.llvm.org/D7526
Reviewed By: Chris Bieneman

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228798 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-11 03:28:02 +00:00
Reid Kleckner
690248bf52 Don't promote asynch EH invokes of nounwind functions to calls
If the landingpad of the invoke is using a personality function that
catches asynch exceptions, then it can catch a trap.

Also add some landingpads to invalid LLVM IR test cases that lack them.

Over-the-shoulder reviewed by David Majnemer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228782 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-11 01:23:16 +00:00
Petar Jovanovic
56e9c5f92b Fix makeLibCall argument (signed) in SoftenFloatRes_XINT_TO_FP function
The isSigned argument of makeLibCall function was hard-coded to false
(unsigned). This caused zero extension on MIPS64 soft float.
As the result SingleSource/Benchmarks/Stanford/FloatMM test and
SingleSource/UnitTests/2005-07-17-INT-To-FP test failed. 
The solution was to use the proper argument.

Patch by Strahinja Petrovic.

Differential Revision: http://reviews.llvm.org/D7292


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228765 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-10 23:30:14 +00:00
Adrian Prantl
7b98f2d2a6 Debug Info: Support variables that are described by more than one MMI
table entry. This happens when SROA splits up an alloca and the resulting
allocas cannot be lowered to SSA values because their address is passed
to a function.

Fixes PR22502.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228764 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-10 23:18:28 +00:00
Adrian Prantl
1e3e40b8c2 Fix indentation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228763 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-10 23:18:15 +00:00
Andrew Kaylor
7741851819 Adding support for llvm.eh.begincatch and llvm.eh.endcatch intrinsics and beginning the documentation of native Windows exception handling.
Differential Revision: http://reviews.llvm.org/D7398



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228733 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-10 19:52:43 +00:00
Jonas Paulsson
b8ee890901 Two comment typo fixes in lib/CodeGen/SelectionDAG/DAGCombiner.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228700 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-10 15:34:29 +00:00
Jonas Paulsson
dacc4cf146 Bugfix for missed dependency from store to load in buildSchedGraph().
Background: When handling underlying objects for a store, the vector
of previous mem uses, mapped to the same Value, is afterwards cleared
(regardless of ThisMayAlias). This means that during handling of the
next store using the same Value, adjustChainDeps() must be called,
otherwise a dependency might be missed.

For example, three spill/reload (NonAliasing) memory accesses using
the same Value 'a', with different offsets:

    SU(2): store  @a
    SU(1): store  @a, Offset:1
    SU(0): load   @a

In this case we have:

* SU(1) does not need a dep against SU(0). Therefore,SU(0) ends up in
  RejectMemNodes and is removed from the mem-uses list (AliasMemUses
  or NonAliasMemUses), as this list is cleared.

* SU(2) needs a dep against SU(0). Therefore, SU(2) must check
  RejectMemNodes by calling adjustChainDeps().

Previously, for store SUs, adjustChainDeps() was only called if
MayAlias was true, missing the S(2) to S(0) dependency in the case
above. The fix is to always call adjustChainDeps(), regardless of
MayAlias, since this applies both for AliasMemUses and
NonAliasMemUses.

No testcase found for any in-tree target.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228686 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-10 13:03:32 +00:00
Chandler Carruth
1c7c2e8650 [x86] Fix PR22524: the DAG combiner was incorrectly handling illegal
nodes when folding bitcasts of constants.

We can't fold things and then check after-the-fact whether it was legal.
Once we have formed the DAG node, arbitrary other nodes may have been
collapsed to it. There is no easy way to go back. Instead, we need to
test for the specific folding cases we're interested in and ensure those
are legal first.

This could in theory make this less powerful for bitcasting from an
integer to some vector type, but AFAICT, that can't actually happen in
the SDAG so its fine. Now, we *only* whitelist specific int->fp and
fp->int bitcasts for post-legalization folding. I've added the test case
from the PR.

(Also as a note, this does not appear to be in 3.6, no backport needed)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228656 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-10 02:25:56 +00:00
Adrian Prantl
4f1b7f3100 Debug info: Use DW_OP_bit_piece instead of DW_OP_piece in the
intermediate representation. This
- increases consistency by using the same granularity everywhere
- allows for pieces < 1 byte
- DW_OP_piece didn't actually allow storing an offset.

Part of PR22495.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228631 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-09 23:57:15 +00:00
Duncan P. N. Exon Smith
99cc7e5307 DebugInfo: Remove DW_TAG_constant
Remove handling for DW_TAG_constant.  We started producing it in
r110656, but reverted that in r110876 without dropping the support.
Finish the job.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228623 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-09 22:48:04 +00:00
Benjamin Kramer
74cdff870f Move DebugLocs around instead of copying.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228491 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-07 12:28:15 +00:00
Bruce Mitchener
8143b4da3f Add more DWARF 5 language constants.
Differential Revision: http://reviews.llvm.org/D7430

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228487 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-07 06:35:30 +00:00
Quentin Colombet
4c2a2ac196 [LiveIntervalAnalysis] Speed up creation of live ranges for physical registers
by using a segment set.

The patch addresses a compile-time performance regression in the LiveIntervals
analysis pass (see http://llvm.org/bugs/show_bug.cgi?id=18580). This regression
is especially critical when compiling long functions. Our analysis had shown
that the most of time is taken for generation of live intervals for physical
registers. Insertions in the middle of the array of live ranges cause quadratic
algorithmic complexity, which is apparently the main reason for the slow-down. 

Overview of changes:
- The patch introduces an additional std::set<Segment>* member in LiveRange for
  storing segments in the phase of initial creation. The set is used if this
  member is not NULL, otherwise everything works the old way. 
- The set of operations on LiveRange used during initial creation (i.e. used by
  createDeadDefs and extendToUses) have been reimplemented to use the segment
  set if it is available.
- After a live range is created the contents of the set are flushed to the
  segment vector, because the set is not as efficient as the vector for the
  later uses of the live range. After the flushing, the set is deleted and
  cannot be used again.
- The set is only for live ranges computed in
  LiveIntervalAnalysis::computeLiveInRegUnits() and getRegUnit() but not in
  computeVirtRegs(), because I did not bring any performance benefits to
  computeVirtRegs() and for some examples even brought a slow down.

Patch by Vaidas Gasiunas <vaidas.gasiunas@sap.com>

Differential Revision: http://reviews.llvm.org/D6013


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228421 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-06 18:42:41 +00:00
Matthias Braun
e81cc348ac LiveInterval: Fix SubRange memory leak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228405 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-06 17:28:47 +00:00
Arnaud A. de Grandmaison
52e57900a3 [PBQP] Fix comment wording. NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228390 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-06 11:28:16 +00:00
Daniel Jasper
c7c2518a65 Small cleanup of MachineLICM.cpp
Specifically:
- Calculate the loop pre-header once at the stat of HoistOutOfLoop, so:
  - We don't-DFS walk the MachineDomTree if we aren't going to do anything
  - Don't call getCurPreheader for each Scope
- Don't needlessly use a do-while loop
- Use early exit for Scopes.size() == 0

No functional changes intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228350 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 22:39:46 +00:00
Ahmed Bougacha
ec35069525 [CodeGen] Add hook/combine to form vector extloads, enabled on X86.
The combine that forms extloads used to be disabled on vector types,
because "None of the supported targets knows how to perform load and
sign extend on vectors in one instruction."

That's not entirely true, since at least SSE4.1 X86 knows how to do
those sextloads/zextloads (with PMOVS/ZX).
But there are several aspects to getting this right.
First, vector extloads are controlled by a profitability callback.
For instance, on ARM, several instructions have folded extload forms,
so it's not always beneficial to create an extload node (and trying to
match extloads is a whole 'nother can of worms).

The interesting optimization enables folding of s/zextloads to illegal
(splittable) vector types, expanding them into smaller legal extloads.

It's not ideal (it introduces some legalization-like behavior in the
combine) but it's better than the obvious alternative: form illegal
extloads, and later try to split them up.  If you do that, you might
generate extloads that can't be split up, but have a valid ext+load
expansion.  At vector-op legalization time, it's too late to generate
this kind of code, so you end up forced to scalarize. It's better to
just avoid creating egregiously illegal nodes.

This optimization is enabled unconditionally on X86.

Note that the splitting combine is happy with "custom" extloads. As
is, this bypasses the actual custom lowering, and just unrolls the
extload. But from what I've seen, this is still much better than the
current custom lowering, which does some kind of unrolling at the end
anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added
FIXME).

Also note that the existing combine that forms extloads is now also
enabled on legal vectors.  This doesn't have a big effect on X86
(because sext+load is usually combined to sext_inreg+aextload).
On ARM it fires on some rare occasions; that's for a separate commit.

Differential Revision: http://reviews.llvm.org/D6904


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
Rafael Espindola
29b65fa1df Add a FIXME.
Thanks to Eric for the suggestion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228300 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 14:57:47 +00:00
Rafael Espindola
e247dd2839 Don' try to make sections in comdats SHF_MERGE.
Parts of llvm were not expecting it and we wouldn't print
the entity size of the section.

Given what comdats are used for, having SHF_MERGE sections would be
just a small improvement, so just disable it for now.

Fixes pr22463.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228196 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-04 21:27:24 +00:00
Matthias Braun
a602c10686 MachineCSE: Clear dead-def flag on CSE.
In case CSE reuses a previoulsy unused register the dead-def flag has to
be cleared on the def operand, as exposed by the arm64-cse.ll test.

This fixes PR22439 and the corresponding rdar://19694987

Differential Revision: http://reviews.llvm.org/D7395

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228178 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-04 19:35:16 +00:00
Michael Kuperstein
8f260e3084 Fixes a bug in vector load legalization that confused bits and bytes.
Differential Revision: http://reviews.llvm.org/D7400

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228168 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-04 18:54:01 +00:00
Owen Anderson
a657cab9ec Remove a gross usage of environment variables in MachineVerifier, replacing it with support for setting the -verify-machineinstrs flag via an environment variable in LIT.
This preserves the handy functionality of force-enabling the MachineVerifier, without the need to embed usage of environment variables in LLVM client applications.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228079 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-04 00:02:59 +00:00
Arnaud A. de Grandmaison
f041861302 [PBQP] Provide more information in the debug prints
Based on a patch by Jonas Paulsson

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228068 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 23:40:24 +00:00
Eric Christopher
b3f0a42d00 Only access TLOF via the TargetMachine, not TargetLowering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227949 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 07:22:52 +00:00
Lang Hames
d54450ef63 [PBQP Regalloc] Pre-spill vregs that have no legal physregs.
The PBQP::RegAlloc::MatrixMetadata class assumes that matrices have at least two
rows/columns (for the spill option plus at least one physreg). This patch
ensures that that invariant is met by pre-spilling vregs that have no physreg
options so that no node (and no corresponding edges) need be added to the PBQP
graph.

This fixes a bug in an out-of-tree target that was identified by Jonas Paulsson.
Thanks for tracking this down Jonas!



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227942 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 06:14:06 +00:00
Rafael Espindola
d273a682a2 Move simple case earlier and use a continue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227841 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-02 19:22:51 +00:00
Adrian Prantl
b265a82d58 Debug Info: Relax assertion in isUnsignedDIType() to allow floats to be
described by integer constants. This is a bit ugly, but if the source
language allows arbitrary type casting, the debug info must follow suit.

For example:
  void foo() {
    float a;
    *(int *)&a = 0;
  }
For the curious: SROA replaces the float alloca with an i32 alloca, which
is then optimized away and described via dbg.value(i32 0, ...).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227827 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-02 18:31:58 +00:00
Michael Kuperstein
acd5f13c88 [X86] Convert esp-relative movs of function arguments to pushes, step 2
This moves the transformation introduced in r223757 into a separate MI pass.
This allows it to cover many more cases (not only cases where there must be a 
reserved call frame), and perform rudimentary call folding. It still doesn't 
have a heuristic, so it is enabled only for optsize/minsize, with stack 
alignment <= 8, where it ought to be a fairly clear win.

(Re-commit of r227728)

Differential Revision: http://reviews.llvm.org/D6789


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227752 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 16:56:04 +00:00
Michael Kuperstein
5b61b8f53c Revert r227728 due to bad line endings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227746 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 16:15:07 +00:00
Chandler Carruth
b71d385494 [multiversion] Switch the TTI queries from TargetMachine to Subtarget
now that we have a correct and cached subtarget specific to the
function.

Also, finish providing a cached per-function subtarget in the core
LLVMTargetMachine -- that layer hadn't switched over yet.

The only use of the TargetMachine was to re-lookup a subtarget for
a particular function to work around the fact that TTI was immutable.
Now that it is per-function and we haved a cached subtarget, use it.

This still leaves a few interfaces with real warts on them where we were
passing Function objects through the TTI interface. I'll remove these
and clean their usage up in subsequent commits now that this isn't
necessary.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227738 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 14:22:17 +00:00
Chandler Carruth
d0bfb83efb [multiversion] Remove the cached TargetMachine pointer from the
intermediate TTI implementation template and instead query up to the
derived class for both the TargetMachine and the TargetLowering.

Most of the derived types had a TLI cached already and there is no need
to store a less precisely typed target machine pointer.

This will in turn make it much cleaner to look up the TLI via
a per-function subtarget instead of the generic subtarget, and it will
pave the way toward pulling the subtarget used for unroll preferences
into the same form once we are *always* using the function to look up
the correct subtarget.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227737 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 14:01:15 +00:00
Chandler Carruth
6e89e1316a [multiversion] Switch all of the targets over to use the
TargetIRAnalysis access path directly rather than implementing getTTI.

This even removes getTTI from the interface. It's more efficient for
each target to just register a precise callback that creates their
specific TTI.

As part of this, all of the targets which are building their subtargets
individually per-function now build their TTI instance with the function
and thus look up the correct subtarget and cache it. NVPTX, R600, and
XCore currently don't leverage this functionality, but its trivial for
them to add it now.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227735 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 13:20:00 +00:00
Chandler Carruth
276f405407 [multiversion] Implement the old pass manager's TTI wrapper pass in
terms of the new pass manager's TargetIRAnalysis.

Yep, this is one of the nicer bits of the new pass manager's design.
Passes can in many cases operate in a vacuum and so we can just nest
things when convenient. This is particularly convenient here as I can
now consolidate all of the TargetMachine logic on this analysis.

The most important change here is that this pushes the function we need
TTI for all the way into the TargetMachine, and re-creates the TTI
object for each function rather than re-using it for each function.
We're now prepared to teach the targets to produce function-specific TTI
objects with specific subtargets cached, etc.

One piece of feedback I'd love here is whether its worth renaming any of
this stuff. None of the names really seem that awesome to me at this
point, but TargetTransformInfoWrapperPass is particularly ... odd.
TargetIRAnalysisWrapper might make more sense. I would want to do that
rename separately anyways, but let me know what you think.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227731 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 12:26:09 +00:00
Chandler Carruth
baceda736e [multiversion] Thread a function argument through all the callers of the
getTTI method used to get an actual TTI object.

No functionality changed. This just threads the argument and ensures
code like the inliner can correctly look up the callee's TTI rather than
using a fixed one.

The next change will use this to implement per-function subtarget usage
by TTI. The changes after that should eliminate the need for FTTI as that
will have become the default.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227730 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 12:01:35 +00:00
Michael Kuperstein
59d9986259 [X86] Convert esp-relative movs of function arguments to pushes, step 2
This moves the transformation introduced in r223757 into a separate MI pass.
This allows it to cover many more cases (not only cases where there must be a 
reserved call frame), and perform rudimentary call folding. It still doesn't 
have a heuristic, so it is enabled only for optsize/minsize, with stack 
alignment <= 8, where it ought to be a fairly clear win.

Differential Revision: http://reviews.llvm.org/D6789

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227728 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 11:44:44 +00:00
Chandler Carruth
1937233a22 [PM] Switch the TargetMachine interface from accepting a pass manager
base which it adds a single analysis pass to, to instead return the type
erased TargetTransformInfo object constructed for that TargetMachine.

This removes all of the pass variants for TTI. There is now a single TTI
*pass* in the Analysis layer. All of the Analysis <-> Target
communication is through the TTI's type erased interface itself. While
the diff is large here, it is nothing more that code motion to make
types available in a header file for use in a different source file
within each target.

I've tried to keep all the doxygen comments and file boilerplate in line
with this move, but let me know if I missed anything.

With this in place, the next step to making TTI work with the new pass
manager is to introduce a really simple new-style analysis that produces
a TTI object via a callback into this routine on the target machine.
Once we have that, we'll have the building blocks necessary to accept
a function argument as well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227685 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 11:17:59 +00:00
Chandler Carruth
a6a87b595d [PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.

The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.

I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.

There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.

The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.

Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.

The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]

Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:

1) Improving the TargetMachine interface by having it directly return
   a TTI object. Because we have a non-pass object with value semantics
   and an internal type erasure mechanism, we can narrow the interface
   of the TargetMachine to *just* do what we need: build and return
   a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
   This will include splitting off a minimal form of it which is
   sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
   target machine for each function. This may actually be done as part
   of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
   easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
   easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
   just a bit messy and exacerbating the complexity of implementing
   the TTI in each target.

Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.

Differential Revision: http://reviews.llvm.org/D7293

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
Alexey Samsonov
d9b3a8244a Fix memory leak in WinEHPrepare introduced in r227405.
This leak was detected by ASan bootstrap of LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227625 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 22:07:05 +00:00
Reid Kleckner
23358b1d74 Update comments to use unreachable instead of llvm.trap, as implemented now
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227502 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 22:32:26 +00:00
Rafael Espindola
9936b80df5 Compute the ELF SectionKind from the flags.
Any code creating an MCSectionELF knows ELF and already provides the flags.

SectionKind is an abstraction used by common code that uses a plain
MCSection.

Use the flags to compute the SectionKind. This removes a lot of
guessing and boilerplate from the MCSectionELF construction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227476 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 17:33:21 +00:00