Targets can provide multiple hints now, so getRegAllocPref() doesn't
make sense any longer because it only returns one preferred register.
Replace it with getSimpleHint() in the remaining heuristics. This
function only

llvm-svn: 169188

No functional change for this commit. The follow-up patch will add more stuff to
these functions.

rdar://12713765

llvm-svn: 169186

llvm-svn: 169183

 This change tries to simmplify E1 = " X >> C1 << C2" into :
  - E2 = "X << (C2 - C1)" if C2 > C1, or
  - E2 = "X >> (C1 - C2)" if C1 > C2, or
  - E2 = X if C1 == C2.

 Reviewed by Nadav. Thanks!

llvm-svn: 169182

Virtual registers with a known preferred register are prioritized by
RAGreedy. This function makes the condition explicit without depending
on getRegAllocPref().

llvm-svn: 169179

This small change adds support for that. It will make all MCJIT tests pass
in make-check on BigEndian platforms.

Patch by Petar Jovanovic.

llvm-svn: 169178

This change adds endian-awareness to MipsJITInfo and emitWordLE in
MipsCodeEmitter has become emitWord now to support both endianness.

Patch by Petar Jovanovic.

llvm-svn: 169177

llvm-svn: 169176

llvm-svn: 169175

code. Removing it.

Patch by Petar Jovanovic.

llvm-svn: 169174

This simplifies the hinting code quite a bit while making the targets
easier to write at the same time.

llvm-svn: 169173

llvm-svn: 169172

llvm-svn: 169171

This provides the same functionality as getRawAllocationOrder() for the
even/odd hints, but without the many constant register arrays.

llvm-svn: 169169

using multiclass.

llvm-svn: 169168

llvm-svn: 169167

llvm-svn: 169166

"Windows.h" includes <Windows.h> which defines a bunch of stuff it shouldn't
(even with all the restriction macros). We have no control over this file, so
make it's scope as small as possible.

llvm-svn: 169165

moves doInitialization and doFinalization to the Pass class and removes some unreachable code in MachineModuleInfo

reviewed by Evan Cheng <evan.cheng@apple.com>

llvm-svn: 169164

llvm-svn: 169163

"single basic block loop vectorizer" to "innermost loop vectorizer".

llvm-svn: 169158

Since this SmallVector immediately grows on the next line, don't waste stack space. SmallVector is still needed due to existing APIs growing their arguments

llvm-svn: 169157

The TargetRegisterInfo::getRegAllocationHints() function is going to
replace the existing mechanisms for providing target-dependent hints to
the register allocator: ResolveRegAllocHint() and
getRawAllocationOrder().

The new hook is more flexible because it allows the target to provide
multiple preferred candidate registers for each virtual register, and it
is easier to use because targets are not required to return a reference
to a constant array like getRawAllocationOrder().

An optional VirtRegMap argument can be used to provide target-dependent
hints that depend on the provisional assignments of other virtual
registers.

llvm-svn: 169154

using multiclass.

llvm-svn: 169153

which is the legality of the if-conversion transformation. The next step is to
implement the cost-model for the if-converted code as well as the
vectorization itself.

llvm-svn: 169152

llvm-svn: 169149

llvm-svn: 169148

For comparison, with this code sample:

PointerUnion<int *, char *> Data;
PointerUnion<int *, char *> foo1() {
	Data = new int;
	return new int;
}
PointerUnion<int *, char *> foo2() {
	Data = new char;
	return new char;
}

Before this patch we would get:

define i64 @_Z4foo1v() uwtable ssp {
  %1 = tail call noalias i8* @_Znwm(i64 4)
  %2 = ptrtoint i8* %1 to i64
  %3 = load i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8
  %4 = and i64 %3, 1
  %.masked.i = and i64 %2, -3
  %5 = or i64 %4, %.masked.i
  store i64 %5, i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8
  %6 = tail call noalias i8* @_Znwm(i64 4)
  %7 = ptrtoint i8* %6 to i64
  %8 = and i64 %7, -3
  ret i64 %8
}

define i64 @_Z4foo2v() uwtable ssp {
  %1 = tail call noalias i8* @_Znwm(i64 1)
  %2 = ptrtoint i8* %1 to i64
  %3 = load i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8
  %4 = and i64 %3, 1
  %5 = or i64 %2, %4
  %6 = or i64 %5, 2
  store i64 %6, i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8
  %7 = tail call noalias i8* @_Znwm(i64 1)
  %8 = ptrtoint i8* %7 to i64
  %9 = or i64 %8, 2
  ret i64 %9
}

After the patch:

define i64 @_Z4foo1v() uwtable ssp {
  %1 = tail call noalias i8* @_Znwm(i64 4)
  %2 = ptrtoint i8* %1 to i64
  store i64 %2, i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8
  %3 = tail call noalias i8* @_Znwm(i64 4)
  %4 = ptrtoint i8* %3 to i64
  ret i64 %4
}

declare noalias i8* @_Znwm(i64)

define i64 @_Z4foo2v() uwtable ssp {
  %1 = tail call noalias i8* @_Znwm(i64 1)
  %2 = ptrtoint i8* %1 to i64
  %3 = or i64 %2, 2
  store i64 %3, i64* getelementptr inbounds (%"class.llvm::PointerUnion"* @Data, i64 0, i32 0, i32 0), align 8
  %4 = tail call noalias i8* @_Znwm(i64 1)
  %5 = ptrtoint i8* %4 to i64
  %6 = or i64 %5, 2
  ret i64 %6
}

llvm-svn: 169147

is not yet good enough for more sophistication. The important goal of this
test is to make sure llc doesn't crash on this IR like it used to.

llvm-svn: 169146

llvm-svn: 169145

llvm-svn: 169143

Thanks Eric for the review.

llvm-svn: 169142

Teach the jump threading optimization to stop scanning the basic block when calculating the cost after passing the threshold.

llvm-svn: 169135

llvm-svn: 169134

AKA: Recompile *ALL* the source code!

This one went much better. No manual edits here. I spot-checked for
silliness and grep-checked for really broken edits and everything seemed
good. It all still compiles. Yell if you see something that looks goofy.

llvm-svn: 169133

Kind of important when prepping the include/... tree version of the sort
changes.

llvm-svn: 169132

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

llvm-svn: 169130

standards.

I am a terrible Python programmer. Patches more the welcome. Please tell
me how this should look if it should look differently. It's just a tiny
little script so it didn't make sense to go through pre-commit review,
especially as someone who actually knows python may want to just rip it
apart and do it The Right Way.

I will be preparing a commit shortly that uses this script to
canonicalize *all* of the #include lines in LLVM. Really, all of them.

llvm-svn: 169125

The partitioning logic attempted to handle uses of an alloca with an
offset starting before the alloca so long as the use had some overlap
with the alloca itself. However, there was a bug where we tested
'(uint64_t)Offset >= AllocSize' without first checking whether 'Offset'
was positive. As a consequence, essentially every negative offset (that
is, starting *before* the alloca does) would be thrown out, even if it
was overlapping. The subsequent code to throw out negative offsets which
were actually non-overlapping was essentially dead. The code to *handle*
overlapping negative offsets was actually dead!

I've just removed all of this, and taught SROA to discard any uses which
start prior to the alloca from the beginning. It has the lovely property
of simplifying the code. =] All the tests still pass, and in fact no new
tests are needed as this is already covered by our testsuite. Fixing the
code so that negative offsets work the way the comments indicate they
were supposed to work causes regressions. That's how I found this.

Anyways, this is all progress in the correct direction -- tightening up
SROA to be maximally aggressive. Some day, I really hope to turn
out-of-bounds accesses to an alloca into 'unreachable'.

llvm-svn: 169120