|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| | llvm-svn: 156019 | 
| | 
| 
| 
| | llvm-svn: 155983 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Aliases for adding a negative immediate when using an explicit 'w'
suffix. E.g.,
        adds.w r2, #-16
        adds.w r2, r2, #-16
        addw r2, #-16
        addw r2, #-16
        addw r2, r2, #-16
rdar://11330769
llvm-svn: 155946 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Expressions for movw/movt don't always have an :upper16: or :lower16:
on them and that's ok. When they don't, it's just a plain [0-65536]
immediate result, effectively the same as a :lower16: variant kind.
rdar://10550147
llvm-svn: 155941 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | The TargetPassManager's default constructor wants to initialize the PassManager
to 'null'. But it's illegal to bind a null reference to a null l-value. Make the
ivar a pointer instead.
PR12468
llvm-svn: 155902 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Replace some assert() calls w/ actual diagnostics. In a perfect world,
there'd be range checks on these values long before things ever reached
this code. For now, though, issuing a better-late-than-never diagnostic
is still a big improvement over assert().
rdar://11347287
llvm-svn: 155851 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This was exposed by SingleSource/UnitTests/Vector/constpool.c.
The computed size of a basic block isn't always a multiple of its known
alignment, and that can introduce extra alignment padding after the
block.
<rdar://problem/11347135>
llvm-svn: 155845 | 
| | 
| 
| 
| 
| 
| 
| 
| | ARM BUILD_VECTORs created after type legalization cannot use i8 or i16
operands, since those types are not legal.  Instead use i32 operands, which
will be implicitly truncated by the BUILD_VECTOR to match the element type.
llvm-svn: 155824 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | The code could search past the end of the basic block when there was
already a constant pool entry after the block.
Test case with giant basic block in SingleSource/UnitTests/Vector/constpool.c
llvm-svn: 155753 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Make sure when parsing the Thumb1 sp+register ADD instruction that
the source and destination operands match. In thumb2, just use the
wide encoding if they don't. In Thumb1, issue a diagnostic.
rdar://11219154
llvm-svn: 155748 | 
| | 
| 
| 
| 
| 
| | Make the operand order of the instruction match that of the asm syntax.
llvm-svn: 155747 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Previously, ARMConstantIslandPass would conservatively compute the
address of an aligned basic block as:
  RoundUpToAlignment(Offset + UnknownPadding)
This worked fine for the layout algorithm itself, but it could fool the
verify() function because it accounts for alignment padding twice: Once
when adding the worst case UnknownPadding, and again by rounding up the
fictional block offset. This meant that when optimizeThumb2Instructions
would shrink an instruction, the conservative distance estimate could
grow. That shouldn't be possible since the woorst case alignment padding
wss already included.
This patch drops the use of RoundUpToAlignment, and depends only on
worst case padding to compute conservative block offsets. This has the
weird effect that the computed offset for an aligned block may not be
aligned.
The important difference is that shrinking an instruction can never
cause the estimated distance between two instructions to grow. The
estimated distance is always larger than the real distance that only the
assembler knows.
<rdar://problem/11339352>
llvm-svn: 155744 | 
| | 
| 
| 
| 
| 
| | <rdar://problem/11325085>.
llvm-svn: 155724 | 
| | 
| 
| 
| | llvm-svn: 155720 | 
| | 
| 
| 
| 
| 
| | the mask operand in the MCInst.
llvm-svn: 155700 | 
| | 
| 
| 
| | llvm-svn: 155686 | 
| | 
| 
| 
| 
| 
| 
| 
| | instructions.
- However, it does support dmb, dsb, isb, mrs, and msr.
rdar://11331541
llvm-svn: 155685 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | The base address for the PC-relative load is Align(PC,4), so it's the
address of the word containing the 16-bit instruction, not the address
of the instruction itself. Ugh.
rdar://11314619
llvm-svn: 155659 | 
| | 
| 
| 
| 
| 
| 
| | On some cores it's a bad idea for performance to mix VFP and NEON instructions
and since these patterns are NEON anyway, the NEON load should be used.
llvm-svn: 155630 | 
| | 
| 
| 
| | llvm-svn: 155626 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | the feature set of v7a. This comes about if the user specifies something like
-arch armv7 -mcpu=cortex-m3. We shouldn't be generating instructions such as
uxtab in this case.
rdar://11318438
llvm-svn: 155601 | 
| | 
| 
| 
| 
| 
| | right-shifted by #32. These are stored as shifts by #0 in the MCInst and correctly marshalled when transforming from or to assembly representation.
llvm-svn: 155565 | 
| | 
| 
| 
| 
| 
| | only targets that want the function get it. This prevents other targets from getting an unused function warning.
llvm-svn: 155538 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | When an instruction match is found, but the subtarget features it
requires are not available (missing floating point unit, or thumb vs arm
mode, for example), issue a diagnostic that identifies what the feature
mismatch is.
rdar://11257547
llvm-svn: 155499 | 
| | 
| 
| 
| 
| 
| 
| 
| | r154362 was supposed to delete this bit, but obviously didn't.
rdar://11305594
llvm-svn: 155465 | 
| | 
| 
| 
| 
| 
| | its vector
llvm-svn: 155439 | 
| | 
| 
| 
| | llvm-svn: 155399 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | on X86 Atom. Some of our tests failed because the tail merging part of
the BranchFolding pass was creating new basic blocks which did not
contain live-in information. When the anti-dependency code in the Post-RA
scheduler ran, it would sometimes rename the register containing
the function return value because the fact that the return value was
live-in to the subsequent block had been lost. To fix this, it is necessary
to run the RegisterScavenging code in the BranchFolding pass.
This patch makes sure that the register scavenging code is invoked
in the X86 subtarget only when post-RA scheduling is being done.
Post RA scheduling in the X86 subtarget is only done for Atom.
This patch adds a new function to the TargetRegisterClass to control
whether or not live-ins should be preserved during branch folding.
This is necessary in order for the anti-dependency optimizations done
during the PostRASchedulerList pass to work properly when doing
Post-RA scheduling for the X86 in general and for the Intel Atom in particular.
The patch adds and invokes the new function trackLivenessAfterRegAlloc()
instead of using the existing requiresRegisterScavenging().
It changes BranchFolding.cpp to call trackLivenessAfterRegAlloc() instead of
requiresRegisterScavenging(). It changes the all the targets that
implemented requiresRegisterScavenging() to also implement
trackLivenessAfterRegAlloc().  
It adds an assertion in the Post RA scheduler to make sure that post RA
liveness information is available when it is needed.
It changes the X86 break-anti-dependencies test to use –mcpu=atom, in order
to avoid running into the added assertion.
Finally, this patch restores the use of anti-dependency checking
(which was turned off temporarily for the 3.1 release) for
Intel Atom in the Post RA scheduler.
Patch by Andy Zhang!
Thanks to Jakob and Anton for their reviews.
llvm-svn: 155395 | 
| | 
| 
| 
| | llvm-svn: 155393 | 
| | 
| 
| 
| | llvm-svn: 155392 | 
| | 
| 
| 
| | llvm-svn: 155387 | 
| | 
| 
| 
| 
| 
| | Found by valgrind.
llvm-svn: 155313 | 
| | 
| 
| 
| 
| 
| | VMUL and VEXT.
llvm-svn: 155258 | 
| | 
| 
| 
| | llvm-svn: 155254 | 
| | 
| 
| 
| 
| 
| 
| 
| | Use the new TwoOperandAliasConstraint to handle lots of the two-operand aliases
for NEON instructions. There's still more to go, but this is a good chunk of
them.
llvm-svn: 155210 | 
| | 
| 
| 
| 
| 
| | since they are equivalent.
llvm-svn: 155188 | 
| | 
| 
| 
| | llvm-svn: 155178 | 
| | 
| 
| 
| 
| 
| | No need for these explicit aliases anymore. Nuke 'em.
llvm-svn: 155173 | 
| | 
| 
| 
| | llvm-svn: 155004 | 
| | 
| 
| 
| 
| 
| | instructions on ARM. Now the diasassembler emmits warnings instead of errors.
llvm-svn: 155002 | 
| | 
| 
| 
| 
| 
| | disassembler. Since the upredicability conditions are complex, C++ code was added to handle them.
llvm-svn: 155001 | 
| | 
| 
| 
| 
| 
| | coprocessor number was removed for this instruction.
llvm-svn: 155000 | 
| | 
| 
| 
| 
| 
| | instructions in the disassembler.
llvm-svn: 154999 | 
| | 
| 
| 
| | llvm-svn: 154953 | 
| | 
| 
| 
| | llvm-svn: 154921 | 
| | 
| 
| 
| | llvm-svn: 154915 | 
| | 
| 
| 
| 
| 
| 
| | instructions with writebacks. And add test a case for all opcodes handed by
DecodeVLD2DupInstruction() in ARMDisassembler.cpp .
llvm-svn: 154884 | 
| | 
| 
| 
| 
| 
| | rdar://11252521
llvm-svn: 154875 | 
| | 
| 
| 
| 
| 
| | rdar://11252521
llvm-svn: 154862 | 
| | 
| 
| 
| 
| 
| | rdar://11252521
llvm-svn: 154840 |