History log of /llvm-project/llvm/lib/Target/X86/X86SelectionDAGInfo.cpp (Results 76 – 86 of 86)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1
# 65f9d19c 28-Feb-2012 Evan Cheng <evan.cheng@apple.com>

Re-commit r151623 with fix. Only issue special no-return calls if it's a direct call.

llvm-svn: 151645


# ee7b8993 28-Feb-2012 Daniel Dunbar <daniel@zuster.org>

Revert r151623 "Some ARM implementaions, e.g. A-series, does return stack prediction. ...", it is breaking the Clang build during the Compiler-RT part.

llvm-svn: 151630


# 87c7b09d 28-Feb-2012 Evan Cheng <evan.cheng@apple.com>

Some ARM implementaions, e.g. A-series, does return stack prediction. That is,
the processor keeps a return addresses stack (RAS) which stores the address
and the instruction execution state of the i

Some ARM implementaions, e.g. A-series, does return stack prediction. That is,
the processor keeps a return addresses stack (RAS) which stores the address
and the instruction execution state of the instruction after a function-call
type branch instruction.

Calling a "noreturn" function with normal call instructions (e.g. bl) can
corrupt RAS and causes 100% return misprediction so LLVM should use a
unconditional branch instead. i.e.
mov lr, pc
b _foo
The "mov lr, pc" is issued in order to get proper backtrace.

rdar://8979299

llvm-svn: 151623

show more ...


Revision tags: llvmorg-3.0.0, llvmorg-3.0.0-rc4, llvmorg-3.0.0-rc3, llvmorg-3.0.0-rc2, llvmorg-3.0.0-rc1
# 229907cd 18-Jul-2011 Chris Lattner <sabre@nondot.org>

land David Blaikie's patch to de-constify Type, with a few tweaks.

llvm-svn: 135375


# 0ab5e2cd 15-Apr-2011 Chris Lattner <sabre@nondot.org>

Fix a ton of comment typos found by codespell. Patch by
Luis Felipe Strano Moraes!

llvm-svn: 129558


Revision tags: llvmorg-2.9.0, llvmorg-2.9.0-rc3, llvmorg-2.9.0-rc2, llvmorg-2.9.0-rc1
# 3e5fbd74 21-Dec-2010 Chris Lattner <sabre@nondot.org>

rename MVT::Flag to MVT::Glue. "Flag" is a terrible name for
something that just glues two nodes together, even if it is
sometimes used for flags.

llvm-svn: 122310


# 98512315 04-Nov-2010 Duncan Sands <baldrick@free.fr>

When passing a huge parameter using the byval mechanism, a long
sequence of loads and stores was being generated to perform the
copy on the x86 targets if the parameter was less than 4 byte
aligned,

When passing a huge parameter using the byval mechanism, a long
sequence of loads and stores was being generated to perform the
copy on the x86 targets if the parameter was less than 4 byte
aligned, causing llc to use up vast amounts of memory and time.
Use a "rep movs" form instead. PR7170.

llvm-svn: 118260

show more ...


Revision tags: llvmorg-2.8.0, llvmorg-2.8.0-rc3
# 4470c2bb 21-Sep-2010 Chris Lattner <sabre@nondot.org>

Fix a bug where the x86 backend would lower memcpy/memset of segment relative operations
into non-segment-relative copies.

llvm-svn: 114402


# 2510de2b 21-Sep-2010 Chris Lattner <sabre@nondot.org>

reimplement memcpy/memmove/memset lowering to use MachinePointerInfo
instead of srcvalue/offset pairs. This corrects SV info for mem
operations whose size is > 32-bits.

llvm-svn: 114401


Revision tags: llvmorg-2.8.0-rc2, llvmorg-2.8.0-rc1, llvmorg-2.8.0-rc0
# bb919dfb 11-May-2010 Dan Gohman <gohman@apple.com>

Implement a bunch more TargetSelectionDAGInfo infrastructure.

Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and
EmitTargetCodeForMemmove out of TargetLowering and into
SelectionDAGInfo to e

Implement a bunch more TargetSelectionDAGInfo infrastructure.

Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and
EmitTargetCodeForMemmove out of TargetLowering and into
SelectionDAGInfo to exercise this.

llvm-svn: 103481

show more ...


Revision tags: llvmorg-2.7.0
# 9becdddc 16-Apr-2010 Dan Gohman <gohman@apple.com>

Add skeleton target-specific SelectionDAGInfo files.

llvm-svn: 101564


1234