Commit Graph

110780 Commits

Author SHA1 Message Date
Matthias Braun
2d1536af06 Let tablegen compute maximum lanemask for regs/regclasses.
Let tablegen compute the combination of subregister lanemasks for all
subregisters in a register/register class. This is preparation for further
work subregister allocation

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223873 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 01:11:56 +00:00
David Majnemer
eca84264a7 AsmParser: Don't crash if a null byte is inside a quoted string
We don't allow Value* to have names which contain null bytes.  The
AsmParser should reject .ll files that try to do this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223869 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 00:43:17 +00:00
Philip Reames
f8225ab80f Extend some comments around GCModuleInfo, GCFunctionInfo, & GCStrategy
Nothing particularly interesting here, just documenting the way the code currently works before I start changing it...



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 00:30:11 +00:00
Nico Weber
24d058a523 cmake: Make SVNVersion.inc work on Windows if svn is called svn.bat.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223864 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 00:10:21 +00:00
Rafael Espindola
d3732d9095 Simplify the handling of aliases in the gold plugin.
The complicated situation is when we have to keep an alias but drop a GV
that is part of the aliasee.

We used to clone the dropped GV and make the clone internal. This is wasteful
as we know the original will be dropped.

With this patch what is done instead is set the linkage of the original to
internal and replace all uses (but the one in the alias) with a new
declaration that takes the name of the old GV. This saves us from having
to copy the body.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223863 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 00:09:35 +00:00
Ahmed Bougacha
605c40341b [ARM] Combine base-updating/post-incrementing vector load/stores.
We used to only combine intrinsics, and turn them into VLD1_UPD/VST1_UPD
when the base pointer is incremented after the load/store.

We can do the same thing for generic load/stores.

Note that we can only combine the first load/store+adds pair in
a sequence (as might be generated for a v16f32 load for instance),
because other combines turn the base pointer addition chain (each
computing the address of the next load, from the address of the last
load) into independent additions (common base pointer + this load's
offset).

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223862 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-10 00:07:37 +00:00
Philip Reames
3490d23337 Remove the Module pointer from GCStrategy and GCMetadataPrinter
In the current implementation, GCStrategy is a part of the ownership structure for the gc metadata which describes a Module. It also contains a reference to the module in question. As a result, GCStrategy instances are essentially Module specific.

I plan to transition away from this design. Instead, a GCStrategy will be owned by the LLVMContext. It will be a lightweight policy object which contains no information about the Modules or Functions involved, but can be easily reached given a Function.

The first step in this transition is to remove the direct Module reference from GCStrategy. This also requires removing the single user of this reference, the GCMetadataPrinter hierarchy. In theory, this will allow the lifetime of the printers to be scoped to the LLVMContext as well, but in practice, I'm not actually changing that. (Yet?)

An alternate design would have been to move the direct Module reference into the GCMetadataPrinter and change the keying of the owning maps to explicitly key off both GCStrategy and Module. I'm open to doing it that way instead, but didn't see much value in preserving the per Module association for GCMetadataPrinters.

The next change in this sequence will be to start unwinding the intertwined ownership between GCStrategy, GCModuleInfo, and GCFunctionInfo.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223859 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 23:57:54 +00:00
Duncan P. N. Exon Smith
ea614a5025 IR: Fix memory corruption in MDNode new/delete
There were two major problems with `MDNode` memory management.

 1. `MDNode::operator new()` called a placement array constructor for
    `MDOperand`.  What?  Each operand needs to be placed individually.

 2. `MDNode::operator delete()` failed to destruct the `MDOperand`s at
    all.

Frankly it's hard to understand how this worked locally, how this
survived an LTO bootstrap, or how it worked on most of the bots.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223858 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 23:56:39 +00:00
David Majnemer
d465762cfd Forgot to add test for r223856
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223857 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 23:51:14 +00:00
David Majnemer
4f5424e74e AsmParser: Verifier that the contents of a hex integer are hex
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223856 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 23:50:38 +00:00
Kaelyn Takata
df7bc4ec73 Rename static functiom "map" to be more descriptive and to avoid
potential confusion with the std::map type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223853 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 23:32:46 +00:00
Duncan P. N. Exon Smith
ae5224d468 IR: Metadata: Detect an RAUW recursion
Speculatively handle a recursion in
`GenericMDNode::handleChangedOperand()`.  I'm hoping this fixes the
failing hexagon bot [1].

[1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/13434

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223849 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 23:04:59 +00:00
Michael Zolotukhin
c9f47d8821 Remove redundant variable.
Tested by adding assert(LoopVectorPreHeader == VecPreheader) on LLVM
test suite and SPECs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223847 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 22:45:07 +00:00
Colin LeMahieu
7d7b761cd0 [Hexagon] [NFC] Cleaning up unused classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223845 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 22:33:26 +00:00
Ahmed Bougacha
5898fd4260 [ARM] Make testcase more explicit. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223841 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 22:08:57 +00:00
Ahmed Bougacha
d9b12d3b11 [ARM] Factor out base-updating VLD/VST combiner function. NFC.
Move the combiner-state check into another function, add a few
small comments, and use a more general type in a cast<>.

In preparation for a future patch.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223834 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 21:30:00 +00:00
Ahmed Bougacha
a1aa4d3b36 [ARM] Move the store combiner function down. NFC.
And flip its final condition.
In preparation for a future patch.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223833 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 21:26:53 +00:00
Ahmed Bougacha
a31421e2dc [ARM] Also support v2f64 vld1/vst1.
It was missing from the VLD1/VST1 handling logic, even though the
corresponding instructions exist (same form as v2i64).

In preparation for a future patch.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223832 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 21:25:00 +00:00
Duncan P. N. Exon Smith
90cd6f1113 IR: Metadata/Value split: RAUW in a deterministic order
RAUW in a deterministic order to try to recover the hexagon bot [1],
whose tests started failing once my GCC fixes were in for r223802.

Otherwise, I'm not sure why tests would fail there and not here.

[1]: http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/13426

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223829 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 21:12:56 +00:00
Rafael Espindola
b2a5bf25f9 Return ErrorOr<std::unique_ptr<Archive>> form getAsArchive.
This is the same return type of Archive::create.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223827 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 21:05:36 +00:00
Hans Wennborg
86704cc355 Try fixing MSVC build after r223802
LLVM_EXPLICIT is only supported by recent version of MSVC, and it seems
the not-so-recent versions get confused about the operator bool() when
tryint to resolve operator== calls.

This removed the operator bool()'s since they don't seem to be used
anyway.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223824 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 20:39:15 +00:00
Colin LeMahieu
11fa90091b [Hexagon] Fixing broken tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223823 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 20:36:53 +00:00
Rafael Espindola
075a8cee5d Rename createIRObjectFile to just create.
It is a static method of IRObjectFile, so having to use
IRObjectFile::createIRObjectFile was redundant.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223822 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 20:36:13 +00:00
Colin LeMahieu
20856353b8 [Hexagon] Updating rr/ri 32/64 transfer encodings and adding tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223821 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 20:23:30 +00:00
Duncan P. N. Exon Smith
b8755d9ddd Fix an MSVC failure from r223802
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223820 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 20:01:40 +00:00
Juergen Ributzka
772744826c [FastISel][AArch64] Fix a missing nullptr check in 'computeAddress'.
The load/store value type is currently not available when lowering the memcpy
intrinsic. Add the missing nullptr check to support this in 'computeAddress'.

Fixes rdar://problem/19178947.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223818 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 19:44:38 +00:00
Colin LeMahieu
260731d108 [Hexagon] Adding word combine dot-new form and replacing old combine opcode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223815 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 19:23:45 +00:00
Chandler Carruth
3508e27903 Revert r223764 which taught instcombine about integer-based elment extraction
patterns.

This is causing Clang to miscompile itself for 32-bit x86 somehow, and likely
also on ARM and PPC. I really don't know how, but reverting now that I've
confirmed this is actually the culprit. I have a reproduction as well and so
should be able to restore this shortly.

This reverts commit r223764.

Original commit log follows:
Teach instcombine to canonicalize "element extraction" from a load of an
integer and "element insertion" into a store of an integer into actual
element extraction, element insertion, and vector loads and stores.

Previously various parts of LLVM (including instcombine itself) would
introduce integer loads and stores into the code as a way of opaquely
loading and storing "bits". In some cases (such as a memcpy of
std::complex<float> object) we will eventually end up using those bits
in non-integer types. In order for SROA to effectively promote the
allocas involved, it splits these "store a bag of bits" integer loads
and stores up into the constituent parts. However, for non-alloca loads
and tsores which remain, it uses integer math to recombine the values
into a large integer to load or store.

All of this would be "fine", except that it forces LLVM to go through
integer math to combine and split up values. While this makes perfect
sense for integers (and in fact is critical for bitfields to end up
lowering efficiently) it is *terrible* for non-integer types, especially
floating point types. We have a much more canonical way of representing
the act of concatenating the bits of two SSA values in LLVM: a vector
and insertelement. This patch teaching InstCombine to use this
representation.

With this patch applied, LLVM will no longer introduce integer math into
the critical path of every loop over std::complex<float> operations such
as those that make up the hot path of ... oh, most HPC code, Eigen, and
any other heavy linear algebra library.

For the record, I looked *extensively* at fixing this in other parts of
the compiler, but it just doesn't work:
- We really do want to canonicalize memcpy and other bit-motion to
  integer loads and stores. SSA values are tremendously more powerful
  than "copy" intrinsics. Not doing this regresses massive amounts of
  LLVM's scalar optimizer.
- We really do need to split up integer loads and stores of this form in
  SROA or every memcpy of a trivially copyable struct will prevent SSA
  formation of the members of that struct. It essentially turns off
  SROA.
- The closest alternative is to actually split the loads and stores when
  partitioning with SROA, but this has all of the downsides historically
  discussed of splitting up loads and stores -- the wide-store
  information is fundamentally lost. We would also see performance
  regressions for bitfield-heavy code and other places where the
  integers aren't really intended to be split without seemingly
  arbitrary logic to treat integers totally differently.
- We *can* effectively fix this in instcombine, so it isn't that hard of
  a choice to make IMO.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223813 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 19:21:16 +00:00
David Majnemer
0247b81ef6 AsmParser: Don't crash on short hex constants for fp128 types
If we see 0xL01, treat it like 0xL00000000000000000000000000000001
instead of crashing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223811 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 19:10:03 +00:00
Duncan P. N. Exon Smith
f700a24774 Fix another GCC build failure from r223802
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:59:09 +00:00
Frederic Riss
63e42c2782 Remove unneeded curly braces.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223809 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:57:39 +00:00
Frederic Riss
53c4c062c1 Reorder the code to avoid inserting at the beginning of a vector.
As per dblaikie suggestion, thanks\!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223808 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:57:34 +00:00
Juergen Ributzka
9512d7f684 Cleanup PatternMatch. NFC.
Tidy up the code a little by using 'auto' when the type is obvious, doxify the
comments, and clang-format the file.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:56:35 +00:00
Duncan P. N. Exon Smith
973ce33e23 Fix a GCC build failure from r223802
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223806 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:52:38 +00:00
Chris Bieneman
eaf5997921 Adding a new option to CMake to disable C++ atexit on llvm-shlib.
Summary:
This is desirable for WebKit and other clients of the llvm-shlib because C++ exit time destructors have a tendency to crash when invoked from multi-threaded applications.

Ideally this option will be temporary, because the ideal fix is to just not have exit time destructors.

Reviewers: chapuni, ributzka

Reviewed By: ributzka

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223805 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:49:55 +00:00
Robert Khasanov
648f7c7eb1 [AVX512] Added lowering for VBROADCASTSS/SD instructions.
Lowering patterns were written through avx512_broadcast_pat multiclass as pattern generates VBROADCAST and COPY_TO_REGCLASS nodes.
Added lowering tests.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223804 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:45:30 +00:00
Duncan P. N. Exon Smith
dad20b2ae2 IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532.  Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.

I have a follow-up patch prepared for `clang`.  If this breaks other
sub-projects, I apologize in advance :(.  Help me compile it on Darwin
I'll try to fix it.  FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.

This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.

Here's a quick guide for updating your code:

  - `Metadata` is the root of a class hierarchy with three main classes:
    `MDNode`, `MDString`, and `ValueAsMetadata`.  It is distinct from
    the `Value` class hierarchy.  It is typeless -- i.e., instances do
    *not* have a `Type`.

  - `MDNode`'s operands are all `Metadata *` (instead of `Value *`).

  - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
    replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.

    If you're referring solely to resolved `MDNode`s -- post graph
    construction -- just use `MDNode*`.

  - `MDNode` (and the rest of `Metadata`) have only limited support for
    `replaceAllUsesWith()`.

    As long as an `MDNode` is pointing at a forward declaration -- the
    result of `MDNode::getTemporary()` -- it maintains a side map of its
    uses and can RAUW itself.  Once the forward declarations are fully
    resolved RAUW support is dropped on the ground.  This means that
    uniquing collisions on changing operands cause nodes to become
    "distinct".  (This already happened fairly commonly, whenever an
    operand went to null.)

    If you're constructing complex (non self-reference) `MDNode` cycles,
    you need to call `MDNode::resolveCycles()` on each node (or on a
    top-level node that somehow references all of the nodes).  Also,
    don't do that.  Metadata cycles (and the RAUW machinery needed to
    construct them) are expensive.

  - An `MDNode` can only refer to a `Constant` through a bridge called
    `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).

    As a side effect, accessing an operand of an `MDNode` that is known
    to be, e.g., `ConstantInt`, takes three steps: first, cast from
    `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
    third, cast down to `ConstantInt`.

    The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
    metadata schema owners transition away from using `Constant`s when
    the type isn't important (and they don't care about referring to
    `GlobalValue`s).

    In the meantime, I've added transitional API to the `mdconst`
    namespace that matches semantics with the old code, in order to
    avoid adding the error-prone three-step equivalent to every call
    site.  If your old code was:

        MDNode *N = foo();
        bar(isa             <ConstantInt>(N->getOperand(0)));
        baz(cast            <ConstantInt>(N->getOperand(1)));
        bak(cast_or_null    <ConstantInt>(N->getOperand(2)));
        bat(dyn_cast        <ConstantInt>(N->getOperand(3)));
        bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));

    you can trivially match its semantics with:

        MDNode *N = foo();
        bar(mdconst::hasa               <ConstantInt>(N->getOperand(0)));
        baz(mdconst::extract            <ConstantInt>(N->getOperand(1)));
        bak(mdconst::extract_or_null    <ConstantInt>(N->getOperand(2)));
        bat(mdconst::dyn_extract        <ConstantInt>(N->getOperand(3)));
        bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));

    and when you transition your metadata schema to `MDInt`:

        MDNode *N = foo();
        bar(isa             <MDInt>(N->getOperand(0)));
        baz(cast            <MDInt>(N->getOperand(1)));
        bak(cast_or_null    <MDInt>(N->getOperand(2)));
        bat(dyn_cast        <MDInt>(N->getOperand(3)));
        bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));

  - A `CallInst` -- specifically, intrinsic instructions -- can refer to
    metadata through a bridge called `MetadataAsValue`.  This is a
    subclass of `Value` where `getType()->isMetadataTy()`.

    `MetadataAsValue` is the *only* class that can legally refer to a
    `LocalAsMetadata`, which is a bridged form of non-`Constant` values
    like `Argument` and `Instruction`.  It can also refer to any other
    `Metadata` subclass.

(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:38:53 +00:00
David Majnemer
db7b69e3a6 AsmParser: Don't crash on malformed attribute groups
This fixes PR21785.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223801 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:33:57 +00:00
Colin LeMahieu
60d733acc5 [Hexagon] Updating predicate register transfers and adding tstbit to allow select selection. Updating ll tests with predicate transfers that previously had nop encodings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223800 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 18:16:49 +00:00
Frederic Riss
fa3c6dea6a Correctly handle complex locations expressions in replaceDbgDeclareForAlloca()
replaceDbgDeclareForAlloca() replaces an alloca by a value storing the
address of what was the alloca. If there is a dbg.declare corresponding
to that alloca, we need to lower it to a dbg.value describing the additional
dereference operation to be performed to get to the underlying variable.
 This is done by adding a DW_OP_deref to the complex location part of the
location description. This deref was added to the end of the operation list,
which is wrong. The expression applies to what is described by the
dbg.{declare,value}, and as we are changing this, we need to apply the
DW_OP_deref as the first operation in the list.

Part of the fix for rdar://19162268.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223799 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 17:55:48 +00:00
Frederic Riss
1be6bc79f6 Deleting empty directories left over from r223794.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223798 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 17:50:27 +00:00
Juergen Ributzka
0ff2059da6 [CGP] Rewrite pattern match for splitBranchCondition to work with Values instead.
Rewrite the pattern match code to work also with Values instead with
Instructions only. Also remove the no longer need matcher (m_Instruction).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223797 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 17:50:10 +00:00
Juergen Ributzka
f3ac16dcb4 Revert "Move function to obtain branch weights into the BranchInst class. NFC."
This reverts commit r223784 and copies the 'ExtractBranchMetadata' to CodeGenPrepare.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223795 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 17:32:12 +00:00
Frederic Riss
574ca2ad28 Revert "Initial dsymutil tool commit."
This reverts commit r223793. The review thread wasn't concluded.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 17:21:50 +00:00
Frederic Riss
08550bc751 Initial dsymutil tool commit.
The goal of this tool is to replicate Darwin's dsymutil functionality
based on LLVM. dsymutil is a DWARF linker. Darwin's linker (ld64) does
not link the debug information, it leaves it in the object files in
relocatable form, but embbeds a `debug map` into the executable that
describes where to find the debug information and how to relocate it.
When releasing/archiving a binary, dsymutil is called to link all the DWARF
information into a `dsym bundle` that can distributed/stored along with
the binary.

With this commit, the LLVM based dsymutil is just able to parse the STABS
debug maps embedded by ld64 in linked binaries (and not all of them, for
example archives aren't supported yet).

Note that the tool directory is called dsymutil, but the executable is
currently called llvm-dsymutil. This discrepancy will disappear once the
tool will be feature complete. At this point the executable will be renamed
to dsymutil, but until then you do not want it to override the system one.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223793 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 17:03:30 +00:00
Bill Schmidt
44603b67b1 [PowerPC 4/4] Enable little-endian support for VSX.
With the foregoing three patches, VSX instructions can be used for
little endian.  This patch removes the restriction that prevented
this, and re-enables the test cases from the first three patches.





git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223792 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 16:59:57 +00:00
Bill Schmidt
9a2a305ed4 [PowerPC 3/4] Little-endian adjustments for VSX vector shuffle
When performing instruction selection for ISD::VECTOR_SHUFFLE, there
is special code for handling v2f64 and v2i64 using VSX instructions.
This code must be adjusted for little-endian.  Because the two inputs
are treated as a double-wide register, we must swap their order for
little endian.  To get the appropriate mask elements to use with the
big-endian biased XXPERMDI instruction, we must reverse their order
and invert the bits.

A new test is added to test the 16 possible values of the shuffle
mask.  It is initially disabled for reasons specified in the test.  It
is re-enabled by patch 4/4.




git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223791 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 16:52:29 +00:00
Rafael Espindola
f214fe8b32 Remember the unmangled name in the plugin.
This allows it to work with non trivial manglings like the one in COFF.

Amusingly, this can be tested with gold, as emit-llvm causes the plugin to
exit before any COFF is generated.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223790 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 16:50:57 +00:00
Bill Schmidt
8eabcf7ce7 Add test cases that were inadvertently omitted from r223783 and r223788
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223789 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 16:44:58 +00:00
Bill Schmidt
03b9f9f2b6 [PowerPC 2/4] Little-endian adjustments for VSX insert/extract operations
For little endian, we need to make some straightforward adjustments in
the code expansions for scalar_to_vector and vector_extract of v2f64.
First, scalar_to_vector must place the scalar into vector element
zero.  However, our implementation of SUBREG_TO_REG will place it into
big-element vector element zero (high-order bits), and for little
endian we need it in the low-order bits.  The LE implementation splats
the high-order doubleword into the low-order doubleword.

Second, the meaning of (vector_extract x, 0) and (vector_extract x, 1)
must be reversed for similar reasons.

A new test is added that tests code generation for insertelement and
extractelement for both element 0 and element 1.  It is disabled in
this patch but enabled in patch 4/4, for reasons stated in the test.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223788 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 16:43:32 +00:00