For whatever the reason, x86 CallingConv::Fast (i.e. fastcc) was not passing scalar arguments in registers. This patch defines a new fastcc CC which is slightly different from the FastCall CC. In addition to passing integer arguments in ECX and EDX, it also specify doubles are passed in 8-byte slots which are 8-byte aligned (instead of 4-byte aligned). This avoids a potential performance hazard where doubles span cacheline boundaries.

llvm-svn: 55807

llvm-svn: 55794

llvm-svn: 55779

llvm-svn: 55777

Dan or Evan, please review.

llvm-svn: 55764

llvm-svn: 55763

Remove code that pad number of bytes to pop for X86_FastCall CC. The code doesn't do the "aligning" for Cygwin, Mingw, and Windows. But aligning it on Darwin and Linux breaks gcc compatibility. That ruled out all the platforms we support!

llvm-svn: 55756

No functional change (and no FE change to generate them).

llvm-svn: 55753

HandlePHINodesInSuccessorBlocks that works FastISel-style. This
allows PHI nodes to be updated correctly while using FastISel.

This also involves some code reorganization; ValueMap and
MBBMap are now members of the FastISel class, so they needn't
be passed around explicitly anymore. Also, SelectInstructions
is changed to SelectInstruction, and only does one instruction
at a time.

llvm-svn: 55746

llvm-svn: 55693

Fix capitalization in #include of FastISel.h.  This unbreaks the build on case-sensitive filesystems.

llvm-svn: 55687

llvm-svn: 55685

Let tblgen only generate fastisel routines, not the class definition. This makes it easier for targets to define its own fastisel class.

llvm-svn: 55679

llvm-svn: 55588

For now, can't mark XOR64rr isAsCheapAsAMove. It's technically correct. But various passes cannot handle remating these.

llvm-svn: 55562

Transform (x << (y&31)) -> (x << y). This takes advantage of the fact x86 shift instructions 2nd operand (shift count) is limited to 0 to 31 (or 63 in the x86-64 case).

llvm-svn: 55558

llvm-svn: 55553

llvm-svn: 55552

llvm-svn: 55548

llvm-svn: 55545

llvm-svn: 55521

llvm-svn: 55512

llvm-svn: 55511

llvm-svn: 55504

llvm-svn: 55486

llvm-svn: 55466

ATOMIC_LOAD_ADD_{8,16,32,64} instead of ATOMIC_LOAD_ADD.
Increased the Hardcoded Constant OpActionsCapacity to match.
Large but boring; no functional change.

This is to support partial-word atomics on ppc; i8 is
not a valid type there, so by the time we get to lowering, the
ATOMIC_LOAD nodes looks the same whether the type was i8 or i32.
The information can be added to the AtomicSDNode, but that is the
largest SDNode; I don't fully understand the SDNode allocation,
but it is sensitive to the largest node size, so increasing
that must be bad.  This is the alternative.

llvm-svn: 55457

SSE2 registers as well as the MMX registers.

llvm-svn: 55436

64-bit registers from 16-bit and smaller memory locations, prefer
instructions that define the entire 64-bit register, to avoid
partial-register updates.

llvm-svn: 55422

llvm-svn: 55394

llvm-svn: 55377

was inserted or not.  This allows bitcast in fast isel to properly handle the case
where an appropriate reg-to-reg copy is not available.

llvm-svn: 55375

assign it to a version of the xmm register with the regclass that matches its
type.  This fixes PR2715, a bug handling some crazy xpcom case in mozilla.

llvm-svn: 55358

llvm-svn: 55348

llvm-svn: 55341

Try approach to moving call address load inside of callseq_start. Now it's done during the preprocess of x86 isel. callseq_start's chain is changed to load's chain node; while load's chain is the last of callseq_start or the loads or copytoreg nodes inserted to move arguments to the right spot.

llvm-svn: 55338

llvm-svn: 55318

instructions on having SSE2.

llvm-svn: 55317

llvm-svn: 55300

/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm-gcc.obj/./gcc/xgcc ... src/libiberty/make-temp-file.c -o make-temp-file.o
Assertion failed: (Node2Index[SU->NodeNum] > Node2Index[I->Dep->NodeNum] && "Wrong topological sorting"), function InitDAGTopologicalSorting, file /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp, line 508.
../../../../llvm-gcc.src/libiberty/hashtab.c:955: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[4]: *** [hashtab.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [multi-do] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libiberty] Error 2
make: *** [all] Error 2

llvm-svn: 55295