The types of register variables no longer need to be specified in output
patterns.

llvm-svn: 177845

This syntax is now preferred:

  def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;

There is no reason to repeat the types in the output pattern.

llvm-svn: 177844

DAG arguments can optionally be named:

  (dag node, node:$name)

With this change, the node is also optional:

  (dag node, node:$name, $name)

The missing node is treated as an UnsetInit, so the above is equivalent
to:

  (dag node, node:$name, ?:$name)

This syntax is useful in output patterns where we currently require the
types of variables to be repeated:

  def : Pat<(subc i32:$b, i32:$c), (SUBCCrr i32:$b, i32:$c)>;

This is preferable:

  def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;

llvm-svn: 177843

llvm-svn: 177842

Contributed-by: Thomas Schwinge <thomas@codesourcery.com>
llvm-svn: 177841

llvm-svn: 177840

OpenCL 1.2 spec. 5.7.3.

llvm-svn: 177839

llvm-svn: 177838

llvm-svn: 177837

No functionality change.

llvm-svn: 177836

Also update the documentation since Sparc is the nicest backend, and
used as an example in WritingAnLLVMBackend.

llvm-svn: 177835

This makes it possible to define instruction patterns like this:

def LDri : F3_2<3, 0b000000,
                (outs IntRegs:$dst), (ins MEMri:$addr),
                "ld [$addr], $dst",
                [(set i32:$dst, (load ADDRri:$addr))]>;
                      ~~~

llvm-svn: 177834

In order for the new ZERO register to be used with MC, etc. we need to specify
its register number (0).

Thanks to Kai for reporting the problem!

llvm-svn: 177833

In preparation for using the new register scavenger capability for providing
more than one register simultaneously, specifically note functions that have
spilled VRSAVE (currently, this can happen only in functions that use the
setjmp intrinsic). As with CR spilling, such functions will need to provide two
emergency spill slots to the scavenger.

No functionality change intended.

llvm-svn: 177832

llvm-svn: 177831

I recently added a BCL instruction definition as part of implementing SjLj
support. This can also be used to MCize bcl emission in the asm printer.

No functionality change intended.

llvm-svn: 177830

The SelectionDAG graph has MVT type labels, not register classes, so
this makes it clearer what is happening.

This notation is also robust against adding more types to the IntRegs
register class.

llvm-svn: 177829

Just like register classes, value types can be used in two ways in
patterns:

  (sext_inreg i32:$src, i16)

In a named leaf node like i32:$src, the value type simply provides the
type of the node directly. This simplifies type inference a lot compared
to the current practice of specifiying types indirectly with register
classes.

As an unnamed leaf node, like i16 above, the value type represents
itself as an MVT::Other immediate.

llvm-svn: 177828

These spilling functions will eventually make use of the register scavenger,
however, they'll do so by taking advantage of PEI's virtual-register-based
delayed scavenging mechanism. As a result, these function parameters will not
be used, and can be removed.

No functionality change intended.

llvm-svn: 177827

Marshall Clow found some divide-by-zero warnings with UBSan in rand's binomial_distribution test.  This eliminates the divide-by-zeros and describes in comments the numerical difficulties the test is having.  Each of the problematic tests are exploring edge cases of the distribution.

llvm-svn: 177826

A register class can appear as a leaf TreePatternNode with and without a
name:

  (COPY_TO_REGCLASS GPR:$src, F8RC)

In a named leaf node like GPR:$src, the register class provides type
information for the named variable represented by the node. The TypeSet
for such a node is the set of value types that the register class can
represent.

In an unnamed leaf node like F8RC above, the register class represents
itself as a kind of immediate. Such a node has the type MVT::i32,
we'll never create a virtual register representing it.

This change makes it possible to remove the special handling of
COPY_TO_REGCLASS in CodeGenDAGPatterns.cpp.

llvm-svn: 177825

This is a start at making the libc++ test suite friendlier to the -fnoexceptions flag.  Although this is not a complete solution, it does reduce the number of test failures on OS X from 467 to 128 on OS X when -fno-exceptions is enabled, and does not impact the number of failures at all when -fno-exceptions is not enabled.  The bulk of this code was donated anonymously.

llvm-svn: 177824

The LR register is unconditionally reserved, and its spilling and restoration
is handled by the prologue/epilogue code. As a result, it is never explicitly
spilled by the register allocator.

No functionality change intended.

llvm-svn: 177823

llvm-svn: 177822

llvm-svn: 177821

Remove the type legality check from the SelectionDAGBuilder when it lowers @llvm.fmuladd to ISD::FMA nodes.
Performing this check unilaterally prevented us from generating FMAs when the incoming IR contained illegal vector types which would eventually be legalized to underlying types that *did* support FMA.
For example, an @llvm.fmuladd on an OpenCL float16 should become a sequence of float4 FMAs, not float4 fmul+fadd's.

NOTE: Because we still call the target-specific profitability hook, individual targets can reinstate the old behavior, if desired, by simply performing the legality check inside their callback hook.  They can also perform more sophisticated legality checks, if, for example, some illegal vector types can be productively implemented as FMAs, but not others.
llvm-svn: 177820

Make clang to mark static stack allocations with lifetime markers to enable a more aggressive stack coloring.
Patch by John McCall with help by Shuxin Yang.
rdar://13115369

llvm-svn: 177819

Change method name ClearRefCount => ClearKnownPositiveRefCount to match the name of the member that it is modifying.

llvm-svn: 177818

off the inferior process so we stand a better chance of understanding
what caused us to send a PT_KILL.
<rdar://problem/12720340> 

llvm-svn: 177817

Now said method matches namewise every other method which refers to
the member KnownPositiveRefCount of the class PtrState.

llvm-svn: 177816

Changing -ccc-install-dir to affect cc1's resource-dir setting broke our
internal LNT tests. After discussing the situation with Jim, we've decided to
pursue an alternate approach. We really want the resource-dir to be located
relative to clang, even when using -ccc-install-dir, but we're going to
add a fallback setting for the libc++ headers if they don't exist alongside
the compiler.

llvm-svn: 177815

<rdar://problem/12281172> 

llvm-svn: 177814

to an out-parameter using the indirect-writeback conversion,
and we copied the current value of the variable to the temporary,
make sure that we register an intrinsic use of that value with
the optimizer so that the value won't get released until we have
a chance to retain it.

rdar://13195034

llvm-svn: 177813

llvm-svn: 177812

Added a python version of the performance tests. It will be good to see if the overhead of python interferes at all with our performance readings. We can try things out with this script and see how things go.

llvm-svn: 177811

llvm-svn: 177810

TemplateSpecializationType during template type diffing.  This allows the
correct printing of diffing qualifiers on templates.

llvm-svn: 177809

- memory delta and time for: target create
- memory delta and time for: setting breakpoint at main by name
- time to launch and hit bp at main
- overall memory of target create + bp main + run to main
- ovarall time of target create + bp main + run to main

llvm-svn: 177808

Exports write() and flush() from SBCommandReturnObject to enable file-like output from Python commands.
e.g.:
def ls(debugger, command, result, internal_dict):
    print >>result,”just “some output”

will produce
(lldb) ls
just “some output
(lldb) 

llvm-svn: 177807

In C, comparisons between signed and unsigned numbers are always done in
unsigned-space. Thus, we should know that "i >= 0U" is always true, even
if 'i' is signed. Similarly, "u >= 0" is also always true, even though '0'
is signed.

Part of <rdar://problem/13239003> (false positives related to std::vector)

llvm-svn: 177806