TLI.computeMaskedBitsForTargetNode from ComputeMaskedBits, since
the former may call back into the latter. This fixes a major
compile time problem on a testcase that happnened to hit this
in a particularly bad way, PR4643.

llvm-svn: 78023

llvm-svn: 77982

llvm-svn: 77974

llvm_report_error already prints "LLVM ERROR:". So stop reporting errors like "LLVM ERROR: llvm: error:" or "LLVM ERROR: ERROR:".

llvm-svn: 77971

support. This isn't immediately interesting, because Legalize
ends up lowering SELECT_CC if the target doesn't support it,
but this simplifies the process.

Also, if the SELECT_CC would be expanded in Legalize, it
can potentially end up with two copies of the condition
expression. By leaving it as SELECT+SETCC, the SELECT can be
expanded into two SELECTs that use a single SETCC.

The two comparisons are usually CSE'd, but depending on
when various expressions get legalized, the comparison
expression could involve calls to library functions, such
that the comparison expression may not be able to be CSE'd.
This will be needed by a future patch.

llvm-svn: 77896

actually characters.

llvm-svn: 77794

llvm-svn: 77774

llvm-svn: 77769

as it is now a MachineFunctionPass, and MachineFunctionPass now handles
this.

llvm-svn: 77760

to the MachineFunction.

llvm-svn: 77753

llvm-svn: 77752

in SelectionDAGLowering::visitTargetIntrinsic.

This removes a bit of special-case code for vector types.  After staring
at it for a while, I managed to convince myself that it is not necessary.
The only case where TLI.getValueType() differs from MVT::getMVT is for iPTR,
so this code could potentially make a difference for a vector of pointers.
But, it looks like that is not supported.  Calling TLI.getValueType() on
a vector of pointers leads to the following sequence of calls:

TargetLowering::getValueType
MVT::getMVT
MVT::getVectorVT(iPTR, num elements)
MVT::getExtendedVectorVT
MVT::getTypeForMVT for iPTR
assertion fails "Type is not extended!"

So, unless I'm really missing something, this bit of code is irrelevant to
the current version of LLVM, which is consistent with the fact that I don't
see this code in other similar places.

llvm-svn: 77747

metadata related, which I'm waiting on to avoid conflicting with Devang.

llvm-svn: 77721

shouldn't do AU.setPreservesCFG(), because even though CodeGen passes
don't modify the LLVM IR CFG, they may modify the MachineFunction CFG,
and passes like MachineLoop are registered with isCFGOnly set to true.

llvm-svn: 77691

llvm-svn: 77685

failures when building assorted projects with clang.

--- Reverse-merging r77654 into '.':
U    include/llvm/CodeGen/Passes.h
U    include/llvm/CodeGen/MachineFunctionPass.h
U    include/llvm/CodeGen/MachineFunction.h
U    include/llvm/CodeGen/LazyLiveness.h
U    include/llvm/CodeGen/SelectionDAGISel.h
D    include/llvm/CodeGen/MachineFunctionAnalysis.h
U    include/llvm/Function.h
U    lib/Target/CellSPU/SPUISelDAGToDAG.cpp
U    lib/Target/PowerPC/PPCISelDAGToDAG.cpp
U    lib/CodeGen/LLVMTargetMachine.cpp
U    lib/CodeGen/MachineVerifier.cpp
U    lib/CodeGen/MachineFunction.cpp
U    lib/CodeGen/PrologEpilogInserter.cpp
U    lib/CodeGen/MachineLoopInfo.cpp
U    lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
D    lib/CodeGen/MachineFunctionAnalysis.cpp
D    lib/CodeGen/MachineFunctionPass.cpp
U    lib/CodeGen/LiveVariables.cpp

llvm-svn: 77661

mechanism. To support this, make MachineFunctionPass a little more
complete.

llvm-svn: 77654

llvm-svn: 77635

Allow targets to define libcall names for mem(cpy,set,move) intrinsics, rather than hardcoding them in DAG lowering.

llvm-svn: 77586

Optimize some common usage patterns of atomic built-ins __sync_add_and_fetch() and __sync_sub_and_fetch. 

When the return value is not used (i.e. only care about the value in the memory), x86 does not have to use add to implement these. Instead, it can use add, sub, inc, dec instructions with the "lock" prefix.

This is currently implemented using a bit of instruction selection trick. The issue is the target independent pattern produces one output and a chain and we want to map it into one that just output a chain. The current trick is to select it into a merge_values with the first definition being an implicit_def. The proper solution is to add new ISD opcodes for the no-output variant. DAG combiner can then transform the node before it gets to target node selection.

Problem #2 is we are adding a whole bunch of x86 atomic instructions when in fact these instructions are identical to the non-lock versions. We need a way to add target specific information to target nodes and have this information carried over to machine instructions. Asm printer (or JIT) can use this information to add the "lock" prefix.

llvm-svn: 77582

llvm-svn: 77516

now that TargetOperandInfo does the heavy lifting.

llvm-svn: 77508

llvm-svn: 77495

llvm-svn: 77494

llvm-svn: 77366

llvm-svn: 77347

it is highly specific to the object file that will be generated in the end,
this introduces a new TargetLoweringObjectFile interface that is implemented
for each of ELF/MachO/COFF/Alpha/PIC16 and XCore.

Though still is still a brutal and ugly refactoring, this is a major step
towards goodness.

This patch also:
1. fixes a bunch of dangling pointer problems in the PIC16 backend.
2. disables the TargetLowering copy ctor which PIC16 was accidentally using.
3. gets us closer to xcore having its own crazy target section flags and
   pic16 not having to shadow sections with its own objects.
4. fixes wierdness where ELF targets would set CStringSection but not
   CStringSection_.  Factor the code better.
5. fixes some bugs in string lowering on ELF targets.

llvm-svn: 77294

llvm-svn: 77247

change.

llvm-svn: 77171

llvm-svn: 77148

llvm-svn: 77039

 - Some clients which used DOUT have moved to DEBUG. We are deprecating the
   "magic" DOUT behavior which avoided calling printing functions when the
   statement was disabled. In addition to being unnecessary magic, it had the
   downside of leaving code in -Asserts builds, and of hiding potentially
   unnecessary computations.

llvm-svn: 77019

Revert the ConstantInt constructors back to their 2.5 forms where possible, thanks to contexts-on-types.  More to come.

llvm-svn: 77011

llvm-svn: 76987

LiveInterval, etc to raw_ostream.

llvm-svn: 76965

llvm-svn: 76962

%0 = malloc [3758096384 x i32]

The "malloc" instruction doesn't support 64-bits correctly (see PR715),
and should be removed.  Victor is actively working on fixing this, in 
the meantime just don't crash.

llvm-svn: 76899

llvm-svn: 76702

be useful, and it's currently unused.  (Some issues: it isn't actually 
rich enough to capture the semantics on many architectures, and
semantics can vary depending on the type being shifted.)

llvm-svn: 76633

llvm-svn: 76598