Enable the loop vectorizer in clang and not in the pass manager, so that we can disable it in clang.

llvm-svn: 170470

Now that the bundle flag aware APIs are all in place, it is possible to
continuously verify the flag consistency.

llvm-svn: 170465

AVX2 before AVX.

llvm-svn: 170464

The new bidirectional bundle flags are redundant, so inadvertent bundle
tearing can be detected in the machine code verifier.

llvm-svn: 170463

To not over constrain the scheduler for ARM in thumb mode, some optimizations  for code size reduction, specific to ARM thumb, are blocked when they add a dependency (like write after read dependency).

Disables this check when code size is the priority, i.e., code is compiled with -Oz.

llvm-svn: 170462

The bundle-related MI flags need to be kept in sync with the neighboring
instructions. Don't allow the bulk flag-setting setFlags() function to
change them.

Also don't copy MI flags when cloning an instruction. The clone's bundle
flags will be set when it is explicitly inserted into a bundle.

llvm-svn: 170459

Remove the instr_iterator versions of the splice() functions. It doesn't
seem useful to be able to splice sequences of instructions that don't
consist of full bundles.

The normal splice functions that take MBB::iterator arguments are not
changed, and they can move whole bundles around without any problems.

llvm-svn: 170456

llvm-svn: 170454

llvm-svn: 170453

llvm-svn: 170452

llvm-svn: 170451

llvm-svn: 170450

llvm-svn: 170449

The single-element ilist::splice() function supports a noop move:

  List.splice(I, List, I);

The corresponding std::list function doesn't allow that, so add a unit
test to document that behavior.

This also means that

  List.splice(I, List, F);

is somewhat surprisingly not equivalent to

  List.splice(I, List, F, next(F));

This patch adds an assertion to catch the illegal case I == F above.
Alternatively, we could make I == F a legal noop, but that would make
ilist differ even more from std::list.

llvm-svn: 170443

LoopVectorize: Emit reductions as log2(vectorsize) shuffles + vector ops instead of scalar operations.

For example on x86 with SSE4.2 a <8 x i8> add reduction becomes
	movdqa	%xmm0, %xmm1
	movhlps	%xmm1, %xmm1            ## xmm1 = xmm1[1,1]
	paddw	%xmm0, %xmm1
	pshufd	$1, %xmm1, %xmm0        ## xmm0 = xmm1[1,0,0,0]
	paddw	%xmm1, %xmm0
	phaddw	%xmm0, %xmm0
	pextrb	$0, %xmm0, %edx

instead of
	pextrb	$2, %xmm0, %esi
	pextrb	$0, %xmm0, %edx
	addb	%sil, %dl
	pextrb	$4, %xmm0, %esi
	addb	%dl, %sil
	pextrb	$6, %xmm0, %edx
	addb	%sil, %dl
	pextrb	$8, %xmm0, %esi
	addb	%dl, %sil
	pextrb	$10, %xmm0, %edi
	pextrb	$14, %xmm0, %edx
	addb	%sil, %dil
	pextrb	$12, %xmm0, %esi
	addb	%dil, %sil
	addb	%sil, %dl

llvm-svn: 170439

llvm-svn: 170438

The normal insert() function takes an MBB::iterator position, and
inserts a stand-alone MachineInstr as before.

The insert() function that takes an MBB::instr_iterator position can
insert instructions inside a bundle, and will now update the bundle
flags correctly when that happens.

When the insert position is between two bundles, it is unclear whether
the instruction should be appended to the previous bundle, prepended to
the next bundle, or stand on its own. The MBB::insert() function doesn't
bundle the instruction in that case, use the MIBundleBuilder class for
that.

llvm-svn: 170437

A register can be associated with several distinct register classes.
For example, on PPC, the floating point registers are each associated with
both F4RC (which holds f32) and F8RC (which holds f64). As a result, this code
would fail when provided with a floating point register and an f64 operand
because it would happen to find the register in the F4RC class first and
return that. From the F4RC class, SDAG would extract f32 as the register
type and then assert because of the invalid implied conversion between
the f64 value and the f32 register.

Instead, search all register classes. If a register class containing the
the requested register has the requested type, then return that register
class. Otherwise, as before, return the first register class found that
contains the requested register.

llvm-svn: 170436

llvm-svn: 170416

into the same file in the future.

llvm-svn: 170414

getScalarSizeInBits could not handle vectors of pointers.

llvm-svn: 170412

llvm-svn: 170410

llvm-svn: 170404

llvm-svn: 170398

instruction.

This isn't strictly necessary at the moment because Thumb2SizeReduction
also copies all MI flags from the old instruction to the new. However, a
future patch will make that kind of direct flag tampering illegal.

llvm-svn: 170395

llvm-svn: 170394

the assembler.

Part of PR14624

llvm-svn: 170390

llvm-svn: 170389

Sadly, this costs us a perfectly good opportunity to use 'goto'.

llvm-svn: 170385

Most code is oblivious to bundles and uses the MBB::iterator which only
visits whole bundles. MBB::erase() operates on whole bundles at a time
as before.

MBB::remove() now refuses to remove bundled instructions. It is not safe
to remove all instructions in a bundle without deleting them since there
is no way of returning pointers to all the removed instructions.

MBB::remove_instr() and MBB::erase_instr() will now update bundle flags
correctly, lifting individual instructions out of bundles while leaving
the remaining bundle intact.

The MachineInstr convenience functions are updated so

  eraseFromParent() erases a whole bundle as before
  eraseFromBundle() erases a single instruction, leaving the rest of its bundle.
  removeFromParent() refuses to operate on bundled instructions, and
  removeFromBundle() lifts a single instruction out of its bundle.

These functions will no longer accidentally split or coalesce bundles -
bundle flags are updated to preserve the existing bundling, and explicit
bundleWith* / unbundleFrom* functions should be used to change the
instruction bundling.

This API update is still a work in progress. I am going to update APIs
first so they maintain bundle flags automatically when possible. Then
I'll add stricter verification of the bundle flags.

llvm-svn: 170384

It must be explicity set in MCPureStreamer because otherwise it will
inherit incorrectly from the parent.

llvm-svn: 170383

llvm-svn: 170381

llvm-svn: 170379

llvm-svn: 170376

llvm-svn: 170374

compilation directory.

This defaults to the current working directory, just as it always has,
but now an assembler can choose to override it with a custom directory.
I've taught llvm-mc about this option and added a test case.

llvm-svn: 170371

llvm-svn: 170369

llvm-svn: 170368

llvm-svn: 170367

checks are in place.  Some minor cleanup as well.

llvm-svn: 170360