* Allow a register node as SelectAddr() base.
* ExternalSymbol -> TargetExternalSymbol as direct function callee.
* Use X86::ESP register rather than CopyFromReg(X86::ESP) as stack ptr for
call parmater passing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25207 91177308-0d34-0410-b5e6-96231b3b80d8
that were overloaded to work before and after the stackifier runs. With the
new clean world, it is possible to write patterns for these instructions: woo!
This also adds a few simple patterns here and there, though there are a lot
still missing. These should be easy to add though. :)
See the comments under "Floating Point Stack Support" for more details on
the new world order.
This patch as absolutely no effect on the generated code, woo!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24899 91177308-0d34-0410-b5e6-96231b3b80d8
This also fixes 177.mesa, the only program that fails with --enable-x86-fastcc
turned on. Given a clean nightly tester run, we should be able to turn it
on by default!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@24578 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new flag to TargetLowering indicating if the target has really cheap
signed division by powers of two, make ppc use it. This will probably go
away in the future.
Implement some more ISD::SDIV folds in the dag combiner
Remove now dead code in the x86 backend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23853 91177308-0d34-0410-b5e6-96231b3b80d8
Though I have done extensive testing, it is possible that this will break
things in configs I can't test. Please let me know if this causes a problem
and I'll fix it ASAP.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23505 91177308-0d34-0410-b5e6-96231b3b80d8
putting it into the constant pool. This allows the isel machinery to
create constants that it will end up deciding are not needed, without them
ending up in the resultant function constant pool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23081 91177308-0d34-0410-b5e6-96231b3b80d8
1 byte loads and other operations. This is bad for store-forwarding on
common CPUs. We now do this:
fnstcw WORD PTR [%ESP]
mov %AX, WORD PTR [%ESP]
instead of:
fnstcw WORD PTR [%ESP]
mov %AL, BYTE PTR [%ESP + 1]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22559 91177308-0d34-0410-b5e6-96231b3b80d8
FP-to-int-in-memory: this exposes the load from the stored slot to the
selection dag, allowing it to be folded into other operaions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22556 91177308-0d34-0410-b5e6-96231b3b80d8
that the X86 does not support to the legalizer. This allows it to be better
optimized, etc, and will help with SSE support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22551 91177308-0d34-0410-b5e6-96231b3b80d8
This is the first incremental patch to implement this feature. It adds no
functionality to LLVM but setup up the information needed from targets in
order to implement the optimization correctly. Each target needs to specify
the maximum number of store operations for conversion of the llvm.memset,
llvm.memcpy, and llvm.memmove intrinsics into a sequence of store operations.
The limit needs to be chosen at the threshold of performance for such an
optimization (generally smallish). The target also needs to specify whether
the target can support unaligned stores for multi-byte store operations.
This helps ensure the optimization doesn't generate code that will trap on
an alignment errors.
More patches to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@22468 91177308-0d34-0410-b5e6-96231b3b80d8
