This includes instructions lwl, lwr, swl and swr.

Patch by Zoran Jovnovic

llvm-svn: 188312

llvm-svn: 188309

Update makeLibCall to return both the call and the chain associated with the libcall instead of just the call. This allows us to specify libcalls that return void.

LowerCallTo returns a pair with the return value of the call as the first
element and the chain associated with the return value as the second element. If
we lower a call that has a void return value, LowerCallTo returns an SDValue
with a NULL SDNode and the chain for the call. Thus makeLibCall by just
returning the first value makes it impossible for you to set up the chain so
that the call is not eliminated as dead code.

I also updated all references to makeLibCall to reflect the new return type.

llvm-svn: 188300

Output DW_AT_stmt_list dwarf debug info as DW_FORM_sec_offset instead of DW_FORM_data4 as it is a section offset (fixes the coff/dwarf debug info statement locations)

llvm-svn: 188297

For COFF only: dwarf debug info output a label reference as a section relative item only when it's one of dw_from strp, sec_offset, ref_addr or op_call_ref instead of going by size.

llvm-svn: 188296

llvm-svn: 188293

llvm-svn: 188288

llvm-svn: 188285

I have moved this logic into clang and opt.

llvm-svn: 188281

../lib/Target/X86/X86ISelLowering.cpp:9715:7: error: unused variable 'OpVT' [-Werror,-Wunused-variable]
  EVT OpVT = Op0.getValueType();
      ^
../lib/Target/X86/X86ISelLowering.cpp:9763:14: error: unused variable 'NumElems' [-Werror,-Wunused-variable]
    unsigned NumElems = VT.getVectorNumElements();

llvm-svn: 188269

llvm-svn: 188268

Lowering for SETCC.

llvm-svn: 188265

This patch introduces changes to MipsAsmParser register parsing routines. The code now follows more deterministic path and makes the code more efficient and easier to maintain.

llvm-svn: 188264

llvm-svn: 188259

Before this, collectAttributes() was operating on a local object.

llvm-svn: 188254

Summary:
We need to do two things:

- Initialize BSSSection in MCObjectFileInfo::InitCOFFMCObjectFileInfo
- Teach TargetLoweringObjectFileCOFF::SelectSectionForGlobal what to do
  with it

This fixes PR16861.

Reviewers: rnk

Reviewed By: rnk

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1361

llvm-svn: 188244

CUs.

Currently only hashes the name of CUs and the names of any children,
but it's an obvious first step to show the framework. The testcase
should continue to be correct, however, as it's an empty TU.

llvm-svn: 188243

to find loops if the From and To instructions were in the same block.

Refactor the code a little now that we need to fill to start the CFG-walking
algorithm with more than one starting basic block sometimes.

Special thanks to Andrew Trick for catching an error in my understanding of
natural loops in code review.

llvm-svn: 188236

llvm-svn: 188234

llvm-svn: 188233

llvm-svn: 188232

e.g. Use Ty->getPointerElementType()
instead of cast<PointerType>(Ty)->getElementType()

llvm-svn: 188223

FileCheck should check to make sure the prefix was found, and not a word
containing it (e.g -check-prefix=BASEREL shouldn't match NOBASEREL).

Patch by Ron Ofir.

llvm-svn: 188221

llvm-svn: 188220

llvm-svn: 188219

undefined and produce an error message instead as this is a non-relocatable
expression with X86 Mach-O.

rdar://8920876

llvm-svn: 188218

llvm-svn: 188217

llvm-svn: 188216

R600 doesn't need to do any scheduling on the SelectionDAG now that it
has a very good MachineScheduler.  Also, using the VLIW SelectionDAG
scheduler was having a major impact on compile times. For example with
the phatk kernel here are the LLVM IR to machine code compile times:

With Sched::VLIW

Total Compile Time:                  1.4890 Seconds (User + System)
SelectionDAG Instruction Scheduling: 1.1670 Seconds (User + System)

With Sched::Source

Total Compile Time:                  0.3330 Seconds (User + System)
SelectionDAG Instruction Scheduling: 0.0070 Seconds (User + System)

The code ouput was identical with both schedulers.  This may not be true
for all programs, but it gives me confidence that there won't be much
reduction, if any, in code quality by using Sched::Source.

llvm-svn: 188215

llvm-svn: 188205

In order to appease people (in Apple) who accuse me for committing "huge change" (?) without proper review. 

Thank Eric for fixing a compile-warning. 

llvm-svn: 188204

llvm-svn: 188203

llvm-svn: 188202

llvm-svn: 188201

llvm-svn: 188200

has been finalized except for sizes and offsets. Update test accordingly.

llvm-svn: 188199

llvm-svn: 188198

llvm-svn: 188195

We support this libcall on all platforms except for OpenBSD (See
lib/Codegen/StackProtector.cpp).

llvm-svn: 188193

llvm-svn: 188191