This allows common sp-offsets to be part of the instruction and is
probably faster on modern CPUs too.

llvm-svn: 179977

With a little help from the frontend, it looks like the standard va_*
intrinsics can do the job.

Also clean up an old bitcast hack in LowerVAARG that dealt with
unaligned double loads. Load SDNodes can specify an alignment now.

Still missing: Calling varargs functions with float arguments.

llvm-svn: 179961

Previously, when spilling 64-bit paired registers, an LDMIA with both
a FrameIndex and an offset was produced. This kind of instruction
shouldn't exist, and the extra operand was being confused with the
predicate, causing aborts later on.

This removes the invalid 0-offset from the instruction being
produced.

llvm-svn: 179956

llvm-svn: 179952

I think it's almost impossible to fold atomic fences profitably under
LLVM/C++11 semantics. As a result, this is now unused and just
cluttering up the target interface.

llvm-svn: 179940

llvm-svn: 179939

The getSwappedPredicate function can be used in other places (such as in
improvements to the PPCCTRLoops pass). Instead of trapping it as a static
function in PPCInstrInfo, move it into PPCPredicates with other
predicate-related things.

No functionality change intended.

llvm-svn: 179926

Add CodeGen support for functions that always return arguments via a new parameter attribute 'returned', which is taken advantage of in target-independent tail call opportunity detection and in ARM call lowering (when placed on an integral first parameter).

llvm-svn: 179925

llvm-svn: 179913

llvm-svn: 179906

trying to move as much FastISel logic as possible out of the main path in
SelectionDAGISel - intermixing them just adds confusion.

llvm-svn: 179902

llvm-svn: 179901

When matching a compare with a subtract where the arguments of the compare are
swapped w.r.t. the arguments of the subtract, we need to negate the predicates
(or CR bit indices) of the users. This, however, is not the same as inverting
the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM
backend seems to do this correctly, but when I adapted the code for the PPC
backend, I introduced an error in this logic.

Comparison optimization is now enabled again by default.

llvm-svn: 179899

Based on the patch by David Nadlinger!

llvm-svn: 179889

llvm-svn: 179875

This patch adds support for recoded (meaning assembly-language compatible to
standard mips32) arithmetic 32-bit instructions.

Patch by Zoran Jovanovic.

llvm-svn: 179873

operand type to uimm16.

Patch by Vladimir Medic.

llvm-svn: 179872

indended.
Part of rdar://13663589

llvm-svn: 179871

qualifiers don't necessarily begin with an identifier (e.g., ::foo::bar).

llvm-svn: 179867

llvm-svn: 179866

llvm-svn: 179865

llvm-svn: 179856

Patch from Mihail Popa

llvm-svn: 179854

llvm-svn: 179847

llvm-svn: 179833

llvm-svn: 179830

InstFlag has a default value of 0 and will simplify the VOP3 patterns.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 179829

llvm-svn: 179820

AT&T dialect.  Test case for r179804 as well.
rdar://13674398 and PR13340.

llvm-svn: 179813

llvm-svn: 179808

This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do
I'm disabling this for now.

llvm-svn: 179807

variant/dialect.  Addresses a FIXME in the emitMnemonicAliases function.
Use and test case to come shortly.
rdar://13688439 and part of PR13340.

llvm-svn: 179804

Many PPC instructions have a so-called 'record form' which stores to a specific
condition register the result of comparing the result of the instruction with
zero (always as a signed comparison). For integer operations on PPC64, this is
always a 64-bit comparison.

This implementation is derived from the implementation in the ARM backend;
there are some differences because PPC condition registers are allocatable
virtual registers (although the record forms always use a specific one), and we
look for a matching subtraction instruction after the compare (but before the
first use) in addition to before it.

llvm-svn: 179802

This pattern started popping up in vectorized min/max reductions.

llvm-svn: 179797

In X86FastISel::X86SelectStore(), improperly aligned stores are rejected and
handled by the DAG-based ISel.  However, X86FastISel::X86SelectLoad() makes
no such requirement.  There doesn't appear to be an x86 architectural
correctness issue with allowing potentially unaligned store instructions.
This patch removes this restriction.

Patch by Jim Stichnot.

llvm-svn: 179774

llvm-svn: 179765

llvm-svn: 179764

llvm-svn: 179751

llvm-svn: 179741

llvm-svn: 179739