Commit Graph

21119 Commits

Author SHA1 Message Date
Duncan P. N. Exon Smith
bcb3a41891 UseListShuffleVector: Remove copy constructor
Remove the copy constructor added in r214178 to appease MSVC17 since it
shouldn't be called at all.  My guess is that explicitly deleting it
will make the compiler happy.  To round out the operations I've also
deleted copy assignment and added move assignment.  Otherwise no
functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214213 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 20:45:52 +00:00
Duncan P. N. Exon Smith
49d1690338 UseListShuffleVector: Code reorganization, NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214212 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 20:45:49 +00:00
Rafael Espindola
75a9d37187 Move the bitcode error enum to the include directory.
This will let users in other libraries know which error occurred. In particular,
it will be possible to check if the parsing failed or if the file is not
bitcode.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214209 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 20:22:46 +00:00
Manman Ren
23ab342d96 [Debug Info] remove DITrivialType and use null to represent unspecified param.
Per feedback on r214111, we are going to use null to represent unspecified
parameter. If the type array is {null}, it means a function that returns void;
If the type array is {null, null}, it means a variadic function that returns
void. In summary if we have more than one element in the type array and the last
element is null, it is a variadic function.

rdar://17628609


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214189 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 18:20:39 +00:00
Justin Bogner
f0fd505d07 ProfileData: Don't redundantly default initialize a member
We're default constructing RecordIterator anyway, so it needn't appear
in the mem-initializer-list.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214182 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 15:56:06 +00:00
NAKAMURA Takumi
b7e87b07bb UseListShuffleVector: Add a copy constructor to appease msc17.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214178 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 12:20:50 +00:00
NAKAMURA Takumi
66c0ebf171 UseListShuffleVector::~UseListShuffleVector(): Fix inappropriate delete. It should be delete[].
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214174 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 09:54:35 +00:00
Jiangning Liu
f3224d0617 Add TargetInstrInfo interface isAsCheapAsAMove.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214158 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 01:55:19 +00:00
Rafael Espindola
16c0d7e5f8 Delete dead code.
It was added 12 years ago, but never used (and in the case of sort, never
implemented).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214150 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-29 00:38:55 +00:00
Duncan P. N. Exon Smith
f575ec435e IR: Optimize size of use-list order shuffle vectors
Since we're storing lots of these, save two-pointers per vector with a
custom type rather than using the relatively heavy `SmallVector`.

Part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214135 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 22:41:50 +00:00
Manman Ren
807538b567 [Debug Info] add DISubroutineType and its creation takes DITypeArray.
DITypeArray is an array of DITypeRef, at its creation, we will create
DITypeRef (i.e use the identifier if the type node has an identifier).

This is the last patch to unique the type array of a subroutine type.

rdar://17628609


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214132 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 22:24:06 +00:00
Eric Christopher
8a865f3b90 Regenerate autoconf, previous updates to the configury haven't
been updating configure.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 22:00:44 +00:00
Duncan P. N. Exon Smith
bd24fe8c7e Bitcode: Serialize (and recover) use-list order
Predict and serialize use-list order in bitcode.  This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.

  - Builds a full value-table up front in the writer, sets up a list of
    use-list orders to write out, and discards the table.  This is a
    simpler first step than determining the order from the various
    overlapping IDs of values on-the-fly.

  - The shuffles stored in the use-list order list have an unnecessarily
    large memory footprint.

  - `blockaddress` expressions cause functions to be materialized
    out-of-order.  For now I've ignored this problem, so use-list orders
    will be wrong for constants used by functions that have block
    addresses taken.  There are a couple of ways to fix this, but I
    don't have a concrete plan yet.

  - When materializing functions lazily, the use-lists for constants
    will not be correct.  This use case is out of scope: what should the
    use-list order be, if it's incomplete?

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214125 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 21:19:41 +00:00
Duncan P. N. Exon Smith
31e6dbfd54 IR: Expose Module::rbegin() and rend()
A follow-up commit for PR5680 needs to visit functions in reverse order.
Expose iterators to allow that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214121 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 21:09:32 +00:00
Manman Ren
3cbd21c987 [Debug Info] add a template class DITypedArray.
Typedef DIArray to DITypedArray<DIDescriptor>. Also typedef DITypeArray as
DITypedArray<DITypeRef>.

This is the third of a series of patches to handle type uniqueing of the
type array for a subroutine type.

This commit should have no functionality change.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214115 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 19:33:20 +00:00
Manman Ren
8e8c1ac702 [Debug Info] rename getTypeArray to getElements, setTypeArray to setArrays.
This is the second of a series of patches to handle type uniqueing of the
type array for a subroutine type.

For vector and array types, getElements returns the array of subranges, so it
is a better name than getTypeArray. Even for class, struct and enum types,
getElements returns the members, which can be subprograms.

setArrays can set up to two arrays, the second is the templates.

This commit should have no functionality change.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214112 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 19:14:13 +00:00
Manman Ren
f9b5976bbd [Debug Info] replace DIUnspecifiedParameter with DITrivialType.
This is the first of a series of patches to handle type uniqueing of the
type array for a subroutine type.

This commit makes sure unspecified_parameter is a DIType to enable converting
the type array for a subroutine type to an array of DITypes.

This commit should have no functionality change. With this commit, we may
change unspecified type to be a DITrivialType instead of a DIType.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214111 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 18:52:30 +00:00
Matt Arsenault
da4e4e3abf Update comment
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214100 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 17:31:37 +00:00
Matt Arsenault
2dd264c8a3 Add alignment value to allowsUnalignedMemoryAccess
Rename to allowsMisalignedMemoryAccess.

On R600, 8 and 16 byte accesses are mostly OK with 4-byte alignment,
and don't need to be split into multiple accesses. Vector loads with
an alignment of the element type are not uncommon in OpenCL code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214055 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 17:46:40 +00:00
Chandler Carruth
8e704b16f1 [ADT] Add a remarkbly useful little helper routine to ArrayRef for
checking whether the ArrayRef is equal to an explicit list of arguments.

This is particularly easy to implement even without variadic templates
because ArrayRef happens to be homogeneously typed. As a consequence we
can use a "clever" wrapper type and default arguments to capture in
a single method many arguments as well as *how many* arguments the user
specified.

Thanks to Dave Blaikie for helping me pull together this little helper.
Suggestions for how to improve or generalize it are of course welcome.
I'll be using it immediately in my follow-up patch. =D

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214041 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-27 01:11:19 +00:00
Chandler Carruth
69359ed45b [SDAG] When performing post-legalize DAG combining, run the legalizer
over each node in the worklist prior to combining.

This allows the combiner to produce new nodes which need to go back
through legalization. This is particularly useful when generating
operands to target specific nodes in a post-legalize DAG combine where
the operands are significantly easier to express as pre-legalized
operations. My immediate use case will be PSHUFB formation where we need
to build a constant shuffle mask with a build_vector node.

This also refactors the relevant functionality in the legalizer to
support this, and updates relevant tests. I've spoken to the R600 folks
and these changes look like improvements to them. The avx512 change
needs to be investigated, I suspect there is a disagreement between the
legalizer and the DAG combiner there, but it seems a minor issue so
leaving it to be re-evaluated after this patch.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214020 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-26 05:49:40 +00:00
Richard Smith
df6b3e5829 [modules] Work around mislayering of MC / Object.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214000 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-26 01:10:32 +00:00
Alex Lorenz
b3a3e591ca coverage: remove empty mapping regions
This patch removes the empty coverage mapping regions.
Those regions were produced by clang's old mapping region generation 
algorithm, but the new algorithm doesn't generate them.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213981 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-25 22:22:24 +00:00
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
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
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
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
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
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
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
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
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
Rafael Espindola
6e1b8585bc Remove dead code.
Every user has been switched to using EngineBuilder.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213871 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 16:02:28 +00:00
Hal Finkel
16fd27b2c3 Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
  1. To preserve noalias function attribute information when inlining
  2. To provide the ability to model block-scope C99 restrict pointers

Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.

What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:

!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }

Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:

... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }

When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.

Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.

[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]

Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213864 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 14:25:39 +00:00
Chandler Carruth
6800393083 [Target] Teach the query interfaces for lowering of extloads and
truncstores to support EVTs and return expand for non-simple ones.

This makes them more consistent with the isLegal... query style methods
and makes using them simpler in many scenarios.

No functionality actually changed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213860 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 12:20:53 +00:00
Hal Finkel
2c7c54c86c AA metadata refactoring (introduce AAMDNodes)
In order to enable the preservation of noalias function parameter information
after inlining, and the representation of block-level __restrict__ pointer
information (etc.), additional kinds of aliasing metadata will be introduced.
This metadata needs to be carried around in AliasAnalysis::Location objects
(and MMOs at the SDAG level), and so we need to generalize the current scheme
(which is hard-coded to just one TBAA MDNode*).

This commit introduces only the necessary refactoring to allow for the
introduction of other aliasing metadata types, but does not actually introduce
any (that will come in a follow-up commit). What it does introduce is a new
AAMDNodes structure to hold all of the aliasing metadata nodes associated with
a particular memory-accessing instruction, and uses that structure instead of
the raw MDNode* in AliasAnalysis::Location, etc.

No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213859 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 12:16:19 +00:00
Duncan P. N. Exon Smith
117dff7bd2 IR: Fix comment from r213824
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213836 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 02:56:59 +00:00
NAKAMURA Takumi
f227bf3b26 Remove a stray semicolon. [-Wpedantic]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213833 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 02:11:24 +00:00
Duncan P. N. Exon Smith
5092384bd3 IR: Add Value::sortUseList()
Add `Value::sortUseList()`, templated on the comparison function to use.

The sort is an iterative merge sort that uses a binomial vector of
already-merged lists to limit the size overhead to `O(1)`.

This is part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213824 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 00:53:19 +00:00
Alex Lorenz
b1365e35cc test commit: remove trailing space
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213770 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-23 17:18:05 +00:00
Chad Rosier
67c325e9f0 [AArch64] Lower sdiv x, pow2 using add + select + shift.
The target-independent DAGcombiner will generate:
asr w1, X, #31 w1 = splat sign bit.
add X, X, w1, lsr #28 X = X + 0 or pow2-1
asr w0, X, asr #4 w0 = X/pow2

However, the add + shifts is expensive, so generate:
add w0, X, 15 w0 = X + pow2-1
cmp X, wzr X - 0
csel X, w0, X, lt X = (X < 0) ? X + pow2-1 : X;
asr w0, X, asr 4 w0 = X/pow2

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213758 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-23 14:57:52 +00:00
Tim Northover
9231148e69 AArch64: remove arm64 triple enumerator.
Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and
invites bugs where only one is checked. In reality, the only legitimate
difference between the two (arm64 usually means iOS) is also present in the OS
part of the triple and that's what should be checked.

We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so
there aren't any LLVM-side test changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213743 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-23 12:32:47 +00:00
NAKAMURA Takumi
c42cab96d7 Trailing whitespace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213711 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-23 00:42:52 +00:00
Lang Hames
daf061cf05 [MCJIT] Refactor and add stub inspection to the RuntimeDyldChecker framework.
This patch introduces a 'stub_addr' builtin that can be used to find the address
of the stub for a given (<file>, <section>, <symbol>) tuple. This address can be
used both to verify the contents of stubs (by loading from the returned address)
and to verify references to stubs (by comparing against the returned address).

Example (1) - Verifying stub contents:

Load 8 bytes (assuming a 64-bit target) from the stub for 'x' in the __text
section of f.o, and compare that value against the addres of 'x'.

# rtdyld-check: *{8}(stub_addr(f.o, __text, x) = x

Example (2) - Verifying references to stubs:

Decode the immediate of the instruction at label 'l', and verify that it's
equal to the offset from the next instruction's PC to the stub for 'y' in the
__text section of f.o (i.e. it's the correct PC-rel difference).

# rtdyld-check: decode_operand(l, 4) = stub_addr(f.o, __text, y) - next_pc(l)
l:
        movq    y@GOTPCREL(%rip), %rax

Since stub inspection requires cooperation with RuntimeDyldImpl this patch
pimpl-ifies RuntimeDyldChecker. Its implementation is moved in to a new class,
RuntimeDyldCheckerImpl, that has access to the definition of RuntimeDyldImpl.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213698 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-22 22:47:39 +00:00
Elena Demikhovsky
bf348c4e46 AVX-512: Fixed intrinsic of VSQRTPS/PD instructions.
I set number and types of parameters according to GCC intrinsics.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213640 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-22 11:07:31 +00:00