We were already requiring 2.5, which meant that people on old linux distros
had to upgrade anyway.

Requiring python 2.6 will make supporting 3.X easier as we can use the 3.X
exception syntax.

According to the discussion on llvmdev, there is not much value is requiring
just 2.6, we may as well just require 2.7.

llvm-svn: 224129

Summary:
This commit enables the MIPS-III target and adds support for code
generation of SELECT nodes. We have to use pseudo-instructions with
custom inserters for these nodes as MIPS-III CPUs do not have
conditional-move instructions.

Depends on D6212

Reviewers: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D6464

llvm-svn: 224128

Added lowering tests.

llvm-svn: 224127

This reapplies r224118 with a fix for test 'misched-code-difference-with-debug.ll'.
That test was failing on some buildbots because it was x86 specific but it was
missing a target triple.
Added an explicit triple to test misched-code-difference-with-debug.ll.

llvm-svn: 224126

llvm-svn: 224125

Summary:
For Mips targets that do not have conditional-move instructions, ie. targets
before MIPS32 and MIPS-IV, we have to insert a diamond control-flow
pattern in order to support SELECT nodes. In order to do that, we add
pseudo-instructions with a custom inserter that emits the necessary
control-flow that selects the correct value.

With this patch we add complete support for code generation of Mips-II targets
based on the LLVM test-suite.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D6212

llvm-svn: 224124

Thanks to Sameer Sahasrabuddhe for the report!

llvm-svn: 224123

No functional change.

llvm-svn: 224122

Test 'misched-code-difference-with-debug.ll' was failing on some buildbots.

llvm-svn: 224121

The proper way to break string literals in these languages is by inserting a "+"
between parts which we don't support yet. So we disable string literal breaking
until then.

llvm-svn: 224120

and vectorizes it. 
 
 Test case :
 
       float hadd(float* a) {
           return (a[0] + a[1]) + (a[2] + a[3]);
        }
 
 
 AArch64 assembly before patch :
 
        ldp	s0, s1, [x0]
 	ldp	s2, s3, [x0, #8]
 	fadd	s0, s0, s1
 	fadd	s1, s2, s3
 	fadd	s0, s0, s1
 	ret
 
 AArch64 assembly after patch :
 
        ldp	d0, d1, [x0]
 	fadd	v0.2s, v0.2s, v1.2s
 	faddp	s0, v0.2s
 	ret

Reviewed Link : http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141208/248531.html

llvm-svn: 224119

This patch fixes the issue reported as PR21807. There was a minor difference
in the generated code depending on the -g flag.

The cause was that with -g the machine scheduler used a different
scheduling strategy. This decision was based on the number of instructions
in a schedule region and included debug instructions in that count.

This patch fixes the issue in MISched and provides a test.

Patch by Russell Gallop!

llvm-svn: 224118

Differential Revision: http://reviews.llvm.org/D6591

llvm-svn: 224117

Differential Revision: http://reviews.llvm.org/D6590

llvm-svn: 224116

The __fp16 type is unconditionally exposed. Since -mfp16-format is not yet
supported, there is not a user switch to change this behaviour. This build
attribute should capture the default behaviour of the compiler, which is to
expose the IEEE 754 version of __fp16.

When -mfp16-format is emitted, that will be the way to control the value of
this build attribute.

Change-Id: I8a46641ff0fd2ef8ad0af5f482a6d1af2ac3f6b0
llvm-svn: 224115

In release builds this is actually possible as without asserts there is 
no testing of the actual read bytes and the variables could be partially
uninitialized.

llvm-svn: 224114

The documentation of parseFile() said that "the resulting File
object may take ownership of the MemoryBuffer." So, whether or not
the ownership of a MemoryBuffer would be taken was not clear.
A FileNode (a subclass of InputElement, which is being deprecated)
keeps the ownership if a File doesn't take it.

This patch makes File always take the ownership of a buffer.
Buffers lifespan is not always the same as File instances.
Files are able to deallocate buffers after parsing the contents.

llvm-svn: 224113

This fixed llvm.org/PR21804 and hopefully a few other strange cases.

Before:
    if (blah_blah(whatever, whatever, [] {
      doo_dah();
      doo_dah();
    })) {
    }
    }

After:
    if (blah_blah(whatever, whatever, [] {
          doo_dah();
          doo_dah();
        })) {
    }
    }

llvm-svn: 224112

llvm-svn: 224111

Don't inherit the volatile-ness of the input pointer to the volatile
operation for memory allocated on the side.

This fixes PR17306.

llvm-svn: 224110

llvm-svn: 224109

llvm-svn: 224108

llvm-svn: 224107

llvm-svn: 224106

llvm-svn: 224105

Remove an unnecessary reference variable that pointed to a unique_ptr variable. Just use the unique_ptr variable directly.

llvm-svn: 224104

Use unique_ptr operator= instead of constructor to make it explicit that there's no conversion occurring.

llvm-svn: 224103

This is a second patch for InputGraph cleanup.

Sorry about the size of the patch, but what I did in this
patch is basically moving code from constructor to a new
method, parse(), so the amount of new code is small.
This has no change in functionality.

We've discussed the issue that we have too many classes
to represent a concept of "file". We have File subclasses
that represent files read from disk. In addition to that,
we have bunch of InputElement subclasses (that are part
of InputGraph) that represent command line arguments for
input file names. InputElement is a wrapper for File.

InputElement has parseFile method. The method instantiates
a File. The File's constructor reads a file from disk and
parses that.

Because parseFile method is called from multiple worker
threads, file parsing is processed in parallel. In other
words, one reason why we needed the wrapper classes is
because a File would start reading a file as soon as it
is instantiated.

So, the reason why we have too many classes here is at
least partly because of the design flaw of File class.
Just like threads in a good threading library, we need
to separate instantiation from "start" method, so that
we can instantiate File objects when we need them (which
should be very fast because it involves only one mmap()
and no real file IO) and use them directly instead of
the wrapper classes. Later, we call parse() on each
file in parallel to let them do actual file IO.

In this design, we can eliminate a reason to have the
wrapper classes.

In order to minimize the size of the patch, I didn't go so
far as to replace the wrapper classes with File classes.
The wrapper classes are still there.

In this patch, we call parse() immediately after
instantiating a File, so this really has no change in
functionality. Eventually the call of parse() should be
moved to Driver::link(). That'll be done in another patch.

llvm-svn: 224102

Enabling COMPILER_RT_INCLUDE_TESTS and updating tests/sanitizer_allocator_test.cc to remove Allocator64 related tests for MIPS.

Reviewed By: samsonov

llvm-svn: 224101

#undef a keyword is generally harmless but used often in configuration scripts.
Also added tests that I forgot to include to commit in r223114.

llvm-svn: 224100

llvm-svn: 224099

 
DW_OP_const <const> doesn't describe a constant value, but a value at a constant address. 
The proper way to describe a constant value is DW_OP_constu <const>, DW_OP_stack_value. 
Added DW_OP_stack_value to the stack. 

Marked incorrect-variable-debugloc1.ll to xfail for PowerPC64, while the the failure (PR21881) 
is being investigated. 

llvm-svn: 224098

Summary:
InstCombine infinite-loops for the testcase added
It is because InstCombine is generating instructions that can be
optimized by itself. Fix by not optimizing frem if the optimized
type is the same as original type.
rdar://problem/19150820

Reviewers: majnemer

Differential Revision: http://reviews.llvm.org/D6634

llvm-svn: 224097

llvm-svn: 224096

llvm-svn: 224095

The returned operand needs to be permuted for the unordered
compares. Also fix incorrectly producing fmin_legacy / fmax_legacy
for f64, which don't exist.

llvm-svn: 224094

llvm-svn: 224093

This is nice for the instruction patterns, but it complicates
min / max matching. The select doesn't have the correct type and would
require looking through the bitcasts for the real float operands.

llvm-svn: 224092

llvm-svn: 224091

llvm-svn: 224090