llvm-svn: 168240

test cases require fixes to fast-isel before the verifier can be enabled.
Part of rdar://12594152

llvm-svn: 168233

At the moment we still require to have an integer induction variable (for example: i++).

llvm-svn: 168231

llvm-svn: 168230

style requirement.

llvm-svn: 168229

Teach SROA rewriteVectorizedStoreInst to handle cases when the loaded value is narrower than the stored value. rdar://12713675

llvm-svn: 168227

llvm-svn: 168226

llvm-svn: 168225

llvm-svn: 168223

llvm-svn: 168221

llvm-svn: 168218

llvm-svn: 168215

They are just useless and prevent SmallVector from picking an optimized codepath
for memcpyable elements.

llvm-svn: 168211

llvm-svn: 168210

llvm-svn: 168208

This patch replaces the hard coded GPR pair [R0, R1] of
Intrinsic:arm_ldrexd and [R2, R3] of Intrinsic:arm_strexd with
even/odd GPRPair reg class.
Similar to the lowering of atomic_64 operation.

llvm-svn: 168207

llvm-svn: 168203

llvm-svn: 168202

llvm-svn: 168201

This fixes PR14359

llvm-svn: 168200

An alias to a function should use pc relative addressing.

llvm-svn: 168199

llvm-svn: 168198

Before, the parser would assert on the following code:

@a2 = global i8 addrspace(1)* @a
@a = addrspace(1) global i8 0

because the type of @a was "i8*" instead of "i8 addrspace(1)*" when parsing
the initializer for @a2.

llvm-svn: 168197

llvm-svn: 168196

llvm-svn: 168195

llvm-svn: 168191

ReleaseNotes.html updates reflecting PPC64 Elf Linux efforts and progress.

llvm-svn: 168189

but wasn't due to the same logic bug that caused PR14361.

llvm-svn: 168186

A PR is being filed to address some code issues here.

llvm-svn: 168185

llvm-svn: 168183

llvm-svn: 168182

replaced by this patch is equivalent to the new logic, but you'd be wrong, and
that's exactly where the bug was.  There's a similar bug in instsimplify which
manifests itself as instsimplify failing to simplify this, rather than doing it
wrong, see next commit.

llvm-svn: 168181

llvm-svn: 168180

llvm-svn: 168178

Patch by Pekka Jääskeläinen!

llvm-svn: 168176

Technically this is still a layering violation but it's header-only which makes
it less harmful. No functionality change.

llvm-svn: 168173

llvm-svn: 168171

llvm-svn: 168166

email address for completeness.

llvm-svn: 168165

Notably, I'm reviewing this stuff already, and this makes it clear I'm
on the hook for it.

I'm relying on Eric Christopher and Michael Spencer to help with Support
when there are platform specific issues, but Chris wants a single point
of contact, and I'm happy with that.

llvm-svn: 168164