llvm-svn: 161122

llvm-svn: 160293

X86MachineFunctionInfo as this is currently only used by X86. If this ever
becomes an issue on another arch (e.g., ARM) then we can hoist it back out.

llvm-svn: 160009

This implements codegen support for accesses to thread-local variables
using the local-dynamic model, and adds a clean-up pass so that the base
address for the TLS block can be re-used between local-dynamic access on
an execution path.

llvm-svn: 157818

Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore.

llvm-svn: 150878

llvm-svn: 146960

This PR basically reports a problem where a crash in generated code
happened due to %rbp being clobbered:

  pushq %rbp
  movq  %rsp, %rbp
  ....
  vmovmskps %ymm12, %ebp
  ....
  movq  %rbp, %rsp
  popq  %rbp
  ret

Since Eric's r123367 commit, the default stack alignment for x86 32-bit
has changed to be 16-bytes. Since then, the MaxStackAlignmentHeuristicPass
hasn't been really used, but with AVX it becomes useful again, since per
ABI compliance we don't always align the stack to 256-bit, but only when
there are 256-bit incoming arguments.

ReserveFP was only used by this pass, but there's no RA target hook that
uses getReserveFP() to check for the presence of FP (since nothing was
triggering the pass to run, the uses of getReserveFP() were removed
through time without being noticed). Change this pass to use
setForceFramePointer, which is properly called by MachineFunction
hasFP method.

The testcase is very big and dependent on RA, not sure if it's worth
adding to test/CodeGen/X86.

llvm-svn: 139939

X86. Modify the pass added in the previous patch to call this new
code.

This new prologues generated will call a libgcc routine (__morestack)
to allocate more stack space from the heap when required

Patch by Sanjoy Das.

llvm-svn: 138812

MachineFunctionInfo subclasses.

llvm-svn: 101634

When a frame pointer is not otherwise required, and dynamic stack alignment
is necessary solely due to the spilling of a register with larger alignment
requirements than the default stack alignment, the frame pointer can be both
used as a general purpose register and a frame pointer. That goes poorly, for
obvious reasons. This patch brings back a bit of old logic for identifying
the use of such registers and conservatively reserves the frame pointer
during register allocation in such cases.

For now, implement for X86 only since it's 32-bit linux which is hitting this,
and we want a targeted fix for 2.7. As a follow-on, this will be expanded
to handle other targets, as theoretically the problem could arise elsewhere
as well.

llvm-svn: 100559

This should fix alot of problems we saw so far, e.g. PRs 5851 & 2936

llvm-svn: 95980

Do not emit callseq instructions around sibcalls. This eliminated some unnecessary stack adjustments.

llvm-svn: 95475

llvm-svn: 72969

llvm-svn: 69127

isReg, etc., from isRegister, etc.

llvm-svn: 57006

and X86FastISel.cpp into X86MachineFunction.h, so that it
can be shared, instead of having each selector keep track
of its own.

llvm-svn: 56825

argument. The x86-64 ABI requires the incoming value of %rdi to
be copied to %rax on exit from a function that is returning a
large C struct.

Also, add a README-X86-64 entry detailing the missed optimization
opportunity and proposing an alternative approach.

llvm-svn: 50075

llvm-svn: 45605

llvm-svn: 45418

enabled by passing -tailcallopt to llc.  The optimization is
performed if the following conditions are satisfied:
* caller/callee are fastcc
* elf/pic is disabled OR
  elf/pic enabled + callee is in module + callee has
  visibility protected or hidden

llvm-svn: 42870

hard to catch bugs with retaddr lowering

llvm-svn: 41104

llvm-svn: 39967

it is defined in.

llvm-svn: 36196

llvm-svn: 30608

llvm-svn: 30549

llvm-svn: 28737

function that is being lowered is forced to use FP. Currently this is only
true for main() / Cygwin.

llvm-svn: 28703