llvm-svn: 201698

    
This is consistent with the way CodeGen acheives this. However, CodeGen
always selects mips32 (even when the architecture is mips64).

llvm-svn: 201694

llvm-svn: 201692

No functional change.

llvm-svn: 201689

Since r201608 got reverted, it is not safe to use private linkage in these cases
until it is committed back.

llvm-svn: 201688

llvm-svn: 201682

llvm-svn: 201681

This causes the LLVMgold plugin to segfault. More information on the
replies to r201608.

llvm-svn: 201669

On x86, shifting a vector by a scalar is significantly cheaper than shifting a
vector by another fully general vector. Unfortunately, because SelectionDAG
operates on just one basic block at a time, the shufflevector instruction that
reveals whether the right-hand side of a shift *is* really a scalar is often
not visible to CodeGen when it's needed.

This adds another handler to CodeGenPrepare, to sink any useful shufflevector
instructions down to the basic block where they're used, predicated on a target
hook (since on other architectures, doing so will often just introduce extra
real work).

rdar://problem/16063505

llvm-svn: 201655

Remove special FP opcode maps and instead add enough MRM_XX formats to handle all the FP operations. This increases format by 1 bit, but decreases opcode map by 1 bit so the TSFlags size doesn't change.

llvm-svn: 201649

llvm-svn: 201646

llvm-svn: 201645

Remove A6/A7 opcode maps. They can all be handled with a TB map, opcode of 0xa6/0xa7, and adding MRM_C0/MRM_E0 forms. Removes 376K from the disassembler tables.

llvm-svn: 201641

This enhances the macro parser to parse and handle parameter qualifications,
which is needed to support required formal parameters in macro definitions.  A
required parameter may not be defaulted (though providing a default value is
accepted with a warning).  This improves GAS compatibility.

Partially addresses PR9248.

llvm-svn: 201630

Rather than using std::pair, create a structure to represent the type.  This is
a preliminary refactoring to enable required parameter handling.  Additional
state is needed to indicate required parameters.  This has a minor side effect
of improving readability by providing more accurate names compared to first and
second.

llvm-svn: 201629

llvm-svn: 201625

When outputting an object we check its section to find its name, but when
looking for the section with -ffunction-section we look for the symbol name.

Break the loop by requesting a name with the private prefix when constructing
the section name. This matches the behavior before r201608.

llvm-svn: 201622

The IR
@foo = private constant i32 42

is valid, but before this patch we would produce an invalid MachO from it. It
was invalid because it would use an L label in a section where the liker needs
the labels in order to atomize it.

One way of fixing it would be to just reject this IR in the backend, but that
would not be very front end friendly.

What this patch does is use an 'l' prefix in sections that we know the linker
requires symbols for atomizing them. This allows frontends to just use
private and not worry about which sections they go to or how the linker handles
them.

One small issue with this strategy is that now a symbol name depends on the
section, which is not available before codegen. This is not a problem in
practice. The reason is that it only happens with private linkage, which will
be ignored by the non codegen users (llvm-nm and llvm-ar).

llvm-svn: 201608

This is quiet a bit less confusing now that TargetData was renamed DataLayout.

llvm-svn: 201606

findOrEmitSection).

Vaidas Gasiunas's patch, r201259, fixed one instance where we were always
allocating sections as text. This patch fixes the remaining buggy call sites.

No test case: This isn't breaking anything that I know of, it's just
inconsistent.

<rdar://problem/15943542>

llvm-svn: 201605

llvm-svn: 201601

TargetData was renamed DataLayout back in r165242.

llvm-svn: 201581

llvm-svn: 201563

BuildMI instructions were not including MachineMemOperand information.
This was discovered by 'SingleSource/Benchmarks/Stanford/Oscar' failing
due to a FrameIndex load incorrectly being hoisted by postra-machine-licm.
No other tests have been found to fail.

llvm-svn: 201562

llvm-svn: 201561

It's rather odd to have the flag enabling and disabling this pass only affect a
single target.

llvm-svn: 201559

llvm-svn: 201558

llvm-svn: 201551

Add a bunch of OpSize32 tags to 64-bit mode only instructions to match their 32-bit mode counterparts for cases where there is also a OpSize16 instruction.

llvm-svn: 201550

llvm-svn: 201546

llvm-svn: 201541

Add an x86 prefix encoding for instructions that would decode to a different instruction with 0xf2/f3/66 were in front of them, but don't themselves have a prefix. For now this doesn't change any bbehavior, but plan to use it to fix some bugs in the disassembler.

llvm-svn: 201538

    ldrd r6, r7 [r2, #15]
simply gives an error and does not triggers an assertion.

As Jim points out, the diagnostic is really strange here,
but fixing that would be more complicated. The missing
comma results in the parser expecting a construct like r2[2],
which is the vector index thing the error message is talking
about. That's not what the user intended, though, and there's
nothing else in the instruction that looks at all like a vector.
Yet more fallout from not having a real parser here and trying
to do context-free generic matching for addressing modes.

rdar://15097243

llvm-svn: 201531

This is implemented by handling assignments to the '.' pseudo symbol
as ".org" directives.

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

llvm-svn: 201530

Fix diassembler handling of rex.b when mod=00/01/10 and bbb=101. Mod=00 should ignore the base register entirely. Mod=01/10 should treat this as R13 plus displacment. Fixes PR18860.

llvm-svn: 201507

llvm-svn: 201502

fix for null VectorizedValue assertion in the SLP Vectorizer (in function vectorizeTree()). radar://16064178

llvm-svn: 201501

Until this point only macro definition with named parameters were parsed but the
names were ignored.  This adds support for using that information for named
parameter instantiation.

In order to support the full semantics of the keyword arguments, the arguments
are no longer lazily initialised since the keyword arguments can be specified
out of order and partially if they are defaulted.  Prepopulate the arguments
with the default value for any defaulted parameters, and then parse the
specified arguments.

This simplies some of the handling of the arguments in the inner loop since
empty arguments simply increment the parameter index and move on.

Note that keyword and positional arguments cannot be mixed.

llvm-svn: 201499

NaCl's ARM ABI uses 16 byte stack alignment, so set that in
ARMSubtarget.cpp.

Using 16 byte alignment exposes an issue in code generation in which a
varargs function leaves a 4 byte gap between the values of r1-r3 saved
to the stack and the following arguments that were passed on the
stack.  (Previously, this code only needed to support 4 byte and 8
byte alignment.)

With this issue, llc generated:

varargs_func:
        sub     sp, sp, #16
        push    {lr}
        sub     sp, sp, #12
        add     r0, sp, #16   // Should be 20
        stm     r0, {r1, r2, r3}
        ldr     r0, .LCPI0_0  // Address of va_list
        add     r1, sp, #16
        str     r1, [r0]
        bl      external_func

Fix the bug by checking for "Align > 4".  Also simplify the code by
using OffsetToAlignment(), and update comments.

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

llvm-svn: 201497

During LSR of one loop we can run into a situation where we have to expand the
start of a recurrence of a loop induction variable in this loop. This start
value is a value derived of the induction variable of a preceeding loop. SCEV
has cannonicalized this value to a different recurrence than the recurrence of
the preceeding loop's induction variable (the type and/or step direction) has
changed). When we come to instantiate this SCEV we created a second induction
variable in this preceeding loop.  This patch tries to base such derived
induction variables of the preceeding loop's induction variable.

This helps twolf on arm and seems to help scimark2 on x86.

Reapply with a fix for the case of a value derived from a pointer.

radar://15970709

llvm-svn: 201496