Commit Graph

106112 Commits

Author SHA1 Message Date
Hal Finkel
8ef7b17dfc Add @llvm.assume, lowering, and some basic properties
This is the first commit in a series that add an @llvm.assume intrinsic which
can be used to provide the optimizer with a condition it may assume to be true
(when the control flow would hit the intrinsic call). Some basic properties are added here:

 - llvm.invariant(true) is dead.
 - llvm.invariant(false) is unreachable (this directly corresponds to the
   documented behavior of MSVC's __assume(0)), so is llvm.invariant(undef).

The intrinsic is tagged as writing arbitrarily, in order to maintain control
dependencies. BasicAA has been updated, however, to return NoModRef for any
particular location-based query so that we don't unnecessarily block code
motion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213973 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 21:13:35 +00:00
Akira Hatanaka
9c5f6b8c65 [stack protector] Add test cases for thumb and thumb2.
<rdar://problem/12475629>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213970 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 19:47:46 +00:00
Akira Hatanaka
0651a556fe [stack protector] Fix a potential security bug in stack protector where the
address of the stack guard was being spilled to the stack.

Previously the address of the stack guard would get spilled to the stack if it
was impossible to keep it in a register. This patch introduces a new target
independent node and pseudo instruction which gets expanded post-RA to a
sequence of instructions that load the stack guard value. Register allocator
can now just remat the value when it can't keep it in a register. 

<rdar://problem/12475629>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213967 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 19:31:34 +00:00
Brad Smith
24dfa53b8a Fix arc4random detection.
Patch by Pascal Stumpf.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213966 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 19:28:44 +00:00
Rafael Espindola
a5e6ff6f7e Remove dead code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213963 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 19:06:39 +00:00
Hal Finkel
e9b6201f4d [PowerPC] Support TLS on PPC32/ELF
Patch by Justin Hibbits!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213960 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 17:47:22 +00:00
Juergen Ributzka
06640d93e0 [FastISel][AArch64] Add support for frameaddress intrinsic.
This commit implements the frameaddress intrinsic for the AArch64 architecture
in FastISel.

There were two test cases that pretty much tested the same, so I combined them
to a single test case.

Fixes <rdar://problem/17811834>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213959 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 17:47:14 +00:00
Duncan P. N. Exon Smith
2602b66b91 Move -verify-use-list-order into llvm-uselistorder
Ugh.  Turns out not even transformation passes link in how to read IR.
I sincerely believe the buildbots will finally agree with my system
after this though.  (I don't really understand why all of this has been
working on my system, but not on all the buildbots.)

Create a new tool called llvm-uselistorder to use for verifying use-list
order.  For now, just dump everything from the (now defunct)
-verify-use-list-order pass into the tool.

This might be a better way to test use-list order anyway.

Part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213957 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 17:13:03 +00:00
David Blaikie
fcfd56262b Reapply "DebugInfo: Don't put fission type units in comdat sections."
This recommits r208930, r208933, and r208975 (by reverting r209338) and
reverts r209529 (the FIXME to readd this functionality once the tools
were fixed) now that DWP has been fixed to cope with a single section
for all fission type units.

Original commit message:

"Since type units in the dwo file are handled by a debug aware tool,
they don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization."

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213956 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 17:11:58 +00:00
Hal Finkel
1d20dd420e Claim AA generally as code owner
As per nominations from Chandler and Arnold.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213955 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 16:45:10 +00:00
Hans Wennborg
d72804ad76 Fix MSVC2012 build error in UseListOrder.cpp
I think the compiler got confused by the nested DEBUG macros.
It was failing with:

  UseListOrder.cpp(80) : error C2059: syntax error : '}'

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213954 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 16:22:13 +00:00
Duncan P. N. Exon Smith
17cb4cb5a3 Bitcode: Don't optimize constants when preserving use-list order
`ValueEnumerator::OptimizeConstants()` creates forward references within
the constant pools, which makes predicting constants' use-list order
difficult.  For now, just disable the optimization.

This can be re-enabled in the future in one of two ways:

  - Enable a limited version of this optimization that doesn't create
    forward references.  One idea is to categorize constants by their
    "height" and make that the top-level sort.

  - Enable it entirely.  This requires predicting how may times each
    constant will be recreated as its operands' and operands' operands'
    (etc.) forward references get resolved.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213953 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 16:13:16 +00:00
David Blaikie
e27d5a0047 Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for functions that do not have top level debug information.
Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson
reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped
provide a reduced reproduction, though the failure wasn't too hard to
guess, and even easier with the example to confirm.

The assertion that the subprogram metadata associated with an
llvm::Function matches the scope data referenced by the DbgLocs on the
instructions in that function is not valid under LTO. In LTO, a C++
inline function might exist in multiple CUs and the subprogram metadata
nodes will refer to the same llvm::Function. In this case, depending on
the order of the CUs, the first intance of the subprogram metadata may
not be the one referenced by the instructions in that function and the
assertion will fail.

A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the
assertion removed and a comment added to explain this situation.

This was then reverted again in r213581 as it caused PR20367. The root
cause of this was the early exit in LiveDebugVariables meant that
spurious DBG_VALUE intrinsics that referenced dead variables were not
removed, causing an assertion/crash later on. The fix is to have
LiveDebugVariables strip all DBG_VALUE intrinsics in functions without
debug info as they're not needed anyway. Test case added to cover this
situation (that occurs when a debug-having function is inlined into a
nodebug function) in test/DebugInfo/X86/nodebug_with_debug_loc.ll

Original commit message:

If a function isn't actually in a CU's subprogram list in the debug info
metadata, ignore all the DebugLocs and don't try to build scopes, track
variables, etc.

While this is possibly a minor optimization, it's also a correctness fix
for an incoming patch that will add assertions to LexicalScopes and the
debug info verifier to ensure that all scope chains lead to debug info
for the current function.

Fix up a few test cases that had broken/incomplete debug info that could
violate this constraint.

Add a test case where this occurs by design (inlining a
debug-info-having function in an attribute nodebug function - we want
this to work because /if/ the nodebug function is then inlined into a
debug-info-having function, it should be fine (and will work fine - we
just stitch the scopes up as usual), but should the inlining not happen
we need to not assert fail either).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213952 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 16:10:16 +00:00
David Blaikie
402cf195af DebugInfo: Fix up some test cases to have more correct debug info metadata.
* Add CUs to the named CU node
* Add missing DW_TAG_subprogram nodes
* Add llvm::Functions to the DW_TAG_subprogram nodes

This cleans up the tests so that they don't break under a
soon-to-be-made change that is more strict about such things.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213951 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 16:05:18 +00:00
Hal Finkel
ac34a28746 Add code owner of scoped-noalias metadata
Add myself as the code owner for the scoped-noalias metadata I've developed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213950 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 15:54:55 +00:00
Hal Finkel
9f0a2a8bd5 Convert noalias parameter attributes into noalias metadata during inlining
This functionality is currently turned off by default.

Part of the motivation for introducing scoped-noalias metadata is to enable the
preservation of noalias parameter attribute information after inlining.
Sometimes this can be inferred from the code in the caller after inlining, but
often we simply lose valuable information.

The overall process if fairly simple:
 1. Create a new unqiue scope domain.
 2. For each (used) noalias parameter, create a new alias scope.
 3. For each pointer, collect the underlying objects. Add a noalias scope for
    each noalias parameter from which we're not derived (and has not been
    captured prior to that point).
 4. Add an alias.scope for each noalias parameter from which we might be
    derived (or has been captured before that point).

Note that the capture checks apply only if one of the underlying objects is not
an identified function-local object.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213949 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 15:50:08 +00:00
Hal Finkel
6f5c609076 Simplify and improve scoped-noalias metadata semantics
In the process of fixing the noalias parameter -> metadata conversion process
that will take place during inlining (which will be committed soon, but not
turned on by default), I have come to realize that the semantics provided by
yesterday's commit are not really what we want. Here's why:

void foo(noalias a, noalias b, noalias c, bool x) {
  *q = x ? a : b;
  *c = *q;
}

Generically, we know that *c does not alias with *a and with *b (so there is an
'and' in what we know we're not), and we know that *q might be derived from *a
or from *b (so there is an 'or' in what we know that we are). So we do not want
the semantics currently, where any noalias scope matching any alias.scope
causes a NoAlias return. What we want to know is that the noalias scopes form a
superset of the alias.scope list (meaning that all the things we know we're not
is a superset of all of things the other instruction might be).

Making that change, however, introduces a composibility problem. If we inline
once, adding the noalias metadata, and then inline again adding more, and we
append new scopes onto the noalias and alias.scope lists each time. But, this
means that we could change what was a NoAlias result previously into a MayAlias
result because we appended an additional scope onto one of the alias.scope
lists. So, instead of giving scopes the ability to have parents (which I had
borrowed from the TBAA implementation, but seems increasingly unlikely to be
useful in practice), I've given them domains. The subset/superset condition now
applies within each domain independently, and we only need it to hold in one
domain. Each time we inline, we add the new scopes in a new scope domain, and
everything now composes nicely. In addition, this simplifies the
implementation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213948 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 15:50:02 +00:00
Duncan P. N. Exon Smith
deb8e30913 Try to fix a layering violation introduced by r213945
The dragonegg buildbot (and others?) started failing after
r213945/r213946 because `llvm-as` wasn't linking in the bitcode reader.
I think moving the verify functions to the same file as the verify pass
should fix the build.  Adding a command-line option for maintaining
use-list order in assembly as a drive-by to prevent warnings about
unused static functions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213947 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 15:41:49 +00:00
Duncan P. N. Exon Smith
d8d3b4dc61 Fix -Werror build after r213945
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213946 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 15:00:02 +00:00
Duncan P. N. Exon Smith
7bf73bd378 IPO: Add use-list-order verifier
Add a -verify-use-list-order pass, which shuffles use-list order, writes
to bitcode, reads back, and verifies that the (shuffled) order matches.

  - The utility functions live in lib/IR/UseListOrder.cpp.

  - Moved (and renamed) the command-line option to enable writing
    use-lists, so that this pass can return early if the use-list orders
    aren't being serialized.

It's not clear that this pass is the right direction long-term (perhaps
a separate tool instead?), but short-term it's a great way to test the
use-list order prototype.  I've added an XFAIL-ed testcase that I'm
hoping to get working pretty quickly.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213945 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 14:49:26 +00:00
Amara Emerson
db4f73f6d9 [ARM] Emit ABI_PCS_R9_use build attribute.
Patch by Ben Foster!

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213944 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 14:03:14 +00:00
Benjamin Kramer
ce63ab327a Run sort_includes.py on the AArch64 backend.
No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213938 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 11:42:14 +00:00
Chandler Carruth
168d0c1430 [cmake] Use the external project machinery for libcxxabi so that it can
be disabled in CMake or relocated if desired.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213936 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 10:27:40 +00:00
NAKAMURA Takumi
c819279437 llvm/test/CodeGen/ARM/inlineasm-global.ll: Add explicit triple to appease targeting *-win32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213933 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 09:55:01 +00:00
NAKAMURA Takumi
c27d6a72fc llvm/test/CodeGen/ARM/inlineasm-global.ll: Avoid specifing source file on llc.
It sometimes confuses FileCheck. Consider the case that path contains 'stmib'. :)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213932 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 09:54:49 +00:00
Chandler Carruth
568ab6a8dc [SDAG] Enable the new assert for out-of-range result numbers in
SDValues, fixing the two bugs left in the regression suite.

The key for both of these was the use a single value type rather than
a VTList which caused an unintentionally single-result merge-value node.
Fix this by getting the appropriate VTList in place.

Doing this exposed that the comments in x86's code abouth how MUL_LOHI
operands are handle is wrong. The bug with the use of out-of-range
result numbers was hiding the bug about the order of operands here (as
best i can tell). There are more places where the code appears to get
this backwards still...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213931 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 09:19:23 +00:00
Chandler Carruth
38ccfe9761 [SDAG] Don't insert the VRBase into a mapping from SDValues when the def
doesn't actually correspond to an SDValue at all. Fixes most of the
remaining asserts on out-of-range SDValue result numbers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213930 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 09:19:18 +00:00
Matt Arsenault
068898df79 Store nodes only have 1 result.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213928 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 07:56:42 +00:00
Chandler Carruth
72d4fa9cc6 [SDAG] Start plumbing an assert into SDValues that we don't form one
with a result number outside the range of results for the node.

I don't know how we managed to not really check this very basic
invariant for so long, but the code is *very* broken at this point.
I have over 270 test failures with the assert enabled. I'm committing it
disabled so that others can join in the cleanup effort and reproduce the
issues. I've also included one of the obvious fixes that I already
found. More fixes to come.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213926 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 07:23:23 +00:00
Akira Hatanaka
642c8bef19 [ARM] In thumb mode, emit directive ".code 16" before file level inline
assembly instructions.

This is necessary to ensure ARM assembler switches to Thumb mode before it
starts assembling the file level inline assembly instructions at the beginning
of a .s file.

<rdar://problem/17757232>



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213924 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 05:12:49 +00:00
Lang Hames
b64f8426f2 [X86] Add comments to clarify some non-obvious lines in the stackmap-nops.ll
testcases.

Based on code review from Philip Reames. Thanks Philip!



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213923 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 04:50:08 +00:00
David Majnemer
b984536dad llvm-vtabledump: use a std::map instead of a StringMap for VBTables
StringMap doesn't guarantee any particular iteration order,
this is suboptimal when comparing llvm-vtabledump's output for two
object files.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213921 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 04:30:11 +00:00
Ehsan Akhgari
2048bc28ff Fix a warning in CoverageMappingReader.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213920 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 02:51:57 +00:00
Lang Hames
76cbffa2a9 [X86] Clarify some stackmap shadow optimization code as based on review
feedback from Eric Christopher.

No functional change.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213917 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 02:29:19 +00:00
Bill Schmidt
2286ae542c [PATCH][PPC64LE] Correct little-endian usage of vmrgh* and vmrgl*.
Because the PowerPC vmrgh* and vmrgl* instructions have a built-in
big-endian bias, it is necessary to swap their inputs in little-endian
mode when using them to implement a vector shuffle.  This was
previously missed in the vector LE implementation.

There was already logic to distinguish between unary and "normal"
vmrg* vector shuffles, so this patch extends that logic to use a third
option:  "swapped" vmrg* vector shuffles that are used for little
endian in place of the "normal" ones.

I've updated the vec-shuffle-le.ll test to check for the expected
register ordering on the generated instructions.

This bug was discovered when testing the LE and ELFv2 patches for
safety if they were backported to 3.4.  A different vectorization
decision was made in 3.4 than on mainline trunk, and that exposed the
problem.  I've verified this fix takes care of that issue.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213915 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 01:55:55 +00:00
Alex Lorenz
65b3fca21f Add code coverage mapping data, reader, and writer.
This patch implements the data structures, the reader and
the writers for the new code coverage mapping system. 
The new code coverage mapping system uses the instrumentation
based profiling to provide code coverage analysis.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213910 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 23:57:54 +00:00
Alex Lorenz
4fbd13626b Add code coverage mapping data, reader, and writer.
This patch implements the data structures, the reader and
the writers for the new code coverage mapping system. 
The new code coverage mapping system uses the instrumentation
based profiling to provide code coverage analysis.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213909 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 23:55:56 +00:00
Kevin Enderby
fb0326ce1b Add an implementation for llvm-nm’s -print-file-name option (aka -o and -A).
The -print-file-name option in llvm-nm is to precede each symbol
with the object file it came from.  While code for the parsing of this
option and its aliases existed there was no code to implement it.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213906 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 23:31:52 +00:00
David Majnemer
51a4c9439c Opportunistically fix the builders
A builder complained that it couldn't find llvm-vtabledump, this is
probably because it wasn't a dependency of the 'test' target.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213905 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 23:26:54 +00:00
David Majnemer
96171327db llvm-vtabledump: A vtable dumper
This tool's job is to dump the vtables inside object files.  It is
currently limited to MS ABI vf- and vb-tables but it will eventually
support Itanium-style v-tables as well.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213903 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 23:14:40 +00:00
Mark Heffernan
d10aa6f8b2 After unrolling a loop with llvm.loop.unroll.count metadata (unroll factor
hint) the loop unroller replaces the llvm.loop.unroll.count metadata with
llvm.loop.unroll.disable metadata to prevent any subsequent unrolling
passes from unrolling more than the hint indicates.  This patch fixes
an issue where loop unrolling could be disabled for other loops as well which
share the same llvm.loop metadata.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213900 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 22:36:40 +00:00
Joerg Sonnenberger
86854be8b1 Don't use 128bit functions on PPC32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213899 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 22:20:10 +00:00
Chandler Carruth
d24d326705 [SDAG] Introduce a combined set to the DAG combiner which tracks nodes
which have successfully round-tripped through the combine phase, and use
this to ensure all operands to DAG nodes are visited by the combiner,
even if they are only added during the combine phase.

This is critical to have the combiner reach nodes that are *introduced*
during combining. Previously these would sometimes be visited and
sometimes not be visited based on whether they happened to end up on the
worklist or not. Now we always run them through the combiner.

This fixes quite a few bad codegen test cases lurking in the suite while
also being more principled. Among these, the TLS codegeneration is
particularly exciting for programs that have this in the critical path
like TSan-instrumented binaries (although I think they engineer to use
a different TLS that is faster anyways).

I've tried to check for compile-time regressions here by running llc
over a merged (but not LTO-ed) clang bitcode file and observed at most
a 3% slowdown in llc. Given that this is essentially a worst case (none
of opt or clang are running at this phase) I think this is tolerable.
The actual LTO case should be even less costly, and the cost in normal
compilation should be negligible.

With this combining logic, it is possible to re-legalize as we combine
which is necessary to implement PSHUFB formation on x86 as
a post-legalize DAG combine (my ultimate goal).

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213898 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 22:15:28 +00:00
Chandler Carruth
1b1fbccf49 [x86] Make vector legalization of extloads work more like the "normal"
vector operation legalization with support for custom target lowering
and fallback to expand when it fails, and use this to implement sext and
anyext load lowering for x86 in a more principled way.

Previously, the x86 backend relied on a target DAG combine to "combine
away" sextload and extload nodes prior to legalization, or would expand
them during legalization with terrible code. This is particularly
problematic because the DAG combine relies on running over non-canonical
DAG nodes at just the right time to match several common and important
patterns. It used a combine rather than lowering because we didn't have
good lowering support, and to expose some tricks being employed to more
combine phases.

With this change it becomes a proper lowering operation, the backend
marks that it can lower these nodes, and I've added support for handling
the canonical forms that don't have direct legal representations such as
sextload of a v4i8 -> v4i64 on AVX1. With this change, our test cases
for this behavior continue to pass even after the DAG combiner beigns
running more systematically over every node.

There is some noise caused by this in the test suite where we actually
use vector extends instead of subregister extraction. This doesn't
really seem like the right thing to do, but is unlikely to be a critical
regression. We do regress in one case where by lowering to the
target-specific patterns early we were able to combine away extraneous
legal math nodes. However, this regression is completely addressed by
switching to a widening based legalization which is what I'm working
toward anyways, so I've just switched the test to that mode.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213897 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 22:09:56 +00:00
Saleem Abdulrasool
24ade3b748 Target: invert condition for Windows
The Microsoft ABI and MSVCRT are considered the canonical C runtime and ABI.
The long double routines are not part of this environment.  However, cygwin and
MinGW both provide supplementary implementations.  Change the condition to
reflect this reality.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213896 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 22:09:06 +00:00
Manman Ren
0349d541d2 Feedback from Hans on r213815. No functionaility change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213895 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 21:13:20 +00:00
Hans Wennborg
dee5e2cf7f Windows: Don't wildcard expand /? or -?
Even if there's a file called c:\a, we want /? to be preserved as
an option, not expanded to a filename.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213894 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 21:09:45 +00:00
Lang Hames
b96e833817 [X86] Optimize stackmap shadows on X86.
This patch minimizes the number of nops that must be emitted on X86 to satisfy
stackmap shadow constraints.

To minimize the number of nops inserted, the X86AsmPrinter now records the
size of the most recent stackmap's shadow in the StackMapShadowTracker class,
and tracks the number of instruction bytes emitted since the that stackmap
instruction was encountered. Padding is emitted (if it is required at all)
immediately before the next stackmap/patchpoint instruction, or at the end of
the basic block.

This optimization should reduce code-size and improve performance for people
using the llvm stackmap intrinsic on X86.

<rdar://problem/14959522>



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213892 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 20:40:55 +00:00
Reid Kleckner
5b93c8af72 Replace an assertion with a fatal error
Frontends are responsible for putting inalloca on parameters that would
be passed in memory and not registers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213891 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 19:53:33 +00:00
Joerg Sonnenberger
1cb9342f32 Use the same .eh_frame encoding for 32bit PPC as on i386.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213890 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 19:25:16 +00:00