The software pipeliner and the packetizer try to break dependence
between the post-increment instruction and the dependent memory
instructions by changing the base register and the offset value.
However, in some cases, the existing logic didn't work properly
and created incorrect offset value.

Patch by Jyotsna Verma.

llvm-svn: 315468

llvm-svn: 315467

The pipeliner is generating a serial sequence that causes poor
register allocation when a post-increment instruction appears
prior to the use of the post-increment register. This occurs when
there is a circular set of dependences involved with a sequence
of instructions in the same cycle. In this case, there is no
serialization of the parallel semantics that will not cause an
additional register to be allocated.

This patch fixes the problem by changing the instructions so that
the post-increment instruction is used by the subsequent
instruction, which enables the register allocator to make a
better decision and not require another register.

Patch by Brendon Cahoon.

llvm-svn: 315466

This relands r315336 after fixing bot breakage.

llvm-svn: 315465

If both taskloop and task directives are used at the same time in one
program, we may ran into the situation when the particular type for task
directive is reused for taskloop directives. Patch fixes this problem.

llvm-svn: 315464

llvm-svn: 315463

Differential Revision: https://reviews.llvm.org/D30295

llvm-svn: 315462

llvm-svn: 315461

Eg:
insert v4i32 V, (v2i16 X), 2 --> shuffle v8i16 V', X', {0,1,2,3,8,9,6,7}

This is a generalization of the IR fold in D38316 to handle insertion into a non-undef vector. 
We may want to abandon that one if we can't find value in squashing the more specific pattern sooner.

We're using the existing legal shuffle target hook to avoid AVX512 horror with vXi1 shuffles.

There may be room for improvement in the shuffle lowering here, but that would be follow-up work.

Differential Revision: https://reviews.llvm.org/D38388

llvm-svn: 315460

llvm-svn: 315459

This reverts commit r315456.

llvm-svn: 315458

The NumFixedArgs field of CallLoweringInfo is used by
TargetLowering::LowerCallTo to determine whether a given argument is passed
using the vararg calling convention or not (specifically, to set IsFixed for
each ISD::OutputArg).

Firstly, CallLoweringInfo::setLibCallee and CallLoweringInfo::setCallee both
incorrectly set NumFixedArgs based on the _previous_ args list. Secondly,
TargetLowering::LowerCallTo failed to increment NumFixedArgs when modifying
the argument list so a pointer is passed for the return value.

If your backend uses the IsFixed property or directly accesses NumFixedArgs, 
it is _possible_ this change could result in codegen changes (although the 
previous behaviour would have been incorrect). No such cases have been
identified during code review for any in-tree architecture.

Differential Revision: https://reviews.llvm.org/D37898

llvm-svn: 315457

This patch adds timestamp verification for swiftmodule files.

 - A new flag is provided to allows us to continue testing of the code
   for embedding the__swift_ast. (git doesn't maintain timestamps)
 - Adds a new test for fat (arm) binaries.

Differential revision: https://reviews.llvm.org/D38686

llvm-svn: 315456

Differential Revision: https://reviews.llvm.org/D38779
Patch by Chih-Mao Chen.

llvm-svn: 315455

llvm-svn: 315454

Treat 'f()' as 'f(void)' rather than a function w/o a prototype.

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia, yaxunl

Subscribers: cfe-commits, echuraev, chapuni

Differential Revision: https://reviews.llvm.org/D33681

Re-apply revision 306653.

llvm-svn: 315453

Reviewers: ioeric

Reviewed By: ioeric

Subscribers: klimek, cfe-commits, arphaman

Differential Revision: https://reviews.llvm.org/D38723

llvm-svn: 315452

Reviewers: atanasyan

Differential Revision: https://reviews.llvm.org/D38620

llvm-svn: 315451

llvm-svn: 315450

llvm-svn: 315449

llvm-svn: 315448

llvm-svn: 315447

Use range_loop where it simplifies.

llvm-svn: 315446

This adds debug tracing to the table-generated assembly instruction matcher,
enabled by the -debug-only=asm-matcher option.

The changes in the target AsmParsers are to add an MCInstrInfo reference under
a consistent name, so that we can use it from table-generated code. This was
already being used this way for targets that use deprecation warnings, but 5
targets did not have it, and Hexagon had it under a different name to the other
backends.

llvm-svn: 315445

* Prevent dumping of characters in DumpDataExtractor() with
  item_byte_size bigger than 8 bytes. This case is not supported by the
  code and results in a crash because the code calls
  DataExtractor::GetMaxU64Bitfield() -> GetMaxU64() that asserts for
  byte size > 8 bytes.
* Teach DataExtractor::GetMaxU64(), GetMaxU32(), GetMaxS64() and
  GetMaxU64_unchecked() how to handle byte sizes that are not a multiple
  of 2. This allows DumpDataExtractor() to dump characters and booleans
  with item_byte_size in the interval of [1, 8] bytes. Values that are
  not a multiple of 2 would previously result in a crash because they
  were not handled by GetMaxU64().

llvm-svn: 315444

Adding this test files now so after another commit that will add a new pattern for
TESTM and TESTNM instructions will show the improvemnts that have been done.

Change-Id: If3908b7f91897d764053312365a2bc1de78b291d
llvm-svn: 315443

llvm-svn: 315442

This is PR34546.

Currently LLD creates output sections even if it has no input sections,
but its command contains an assignment.
Committed code just assigns the same flag that was used in previous
live section.
That does not work sometimes. For example if we have following script:

.ARM.exidx : { *(.ARM.exidx*) }
.foo : { _foo = 0; } }
Then first section has SHF_LINK_ORDER flag. But section foo should not.
That was a reason of crash in OutputSection::finalize(). LLD tried to calculate
Link value, calling front() on empty input sections list.
We should only keep access flags and omit all others when creating such sections.

Patch fixes the crash observed.

Differential revision: https://reviews.llvm.org/D37736

llvm-svn: 315441

This patch fixes the miscompile that happens when PRE hoists loads across guards and
other instructions that don't always pass control flow to their successors. PRE is now prohibited
to hoist across such instructions because there is no guarantee that the load standing after such
instruction is still valid before such instruction. For example, a load from under a guard may be
invalid before the guard in the following case:
  int array[LEN];
  ...
  guard(0 <= index && index < LEN);
  use(array[index]);

Differential Revision: https://reviews.llvm.org/D37460

llvm-svn: 315440

This is breaking a build of https://github.com/abseil/abseil-cpp and so
likely not really NFC. Also reverted subsequent r314956/7.

I'll forward reproduction instructions to Richard.

llvm-svn: 315439

Sinking of unordered atomic load into loop must be disallowed because it turns
a single load into multiple loads. The relevant section of the documentation
is: http://llvm.org/docs/Atomics.html#unordered, specifically the Notes for
Optimizers section. Here is the full text of this section:

> Notes for optimizers
> In terms of the optimizer, this **prohibits any transformation that
> transforms a single load into multiple loads**, transforms a store into
> multiple stores, narrows a store, or stores a value which would not be
> stored otherwise. Some examples of unsafe optimizations are narrowing
> an assignment into a bitfield, rematerializing a load, and turning loads
> and stores into a memcpy call. Reordering unordered operations is safe,
> though, and optimizers should take advantage of that because unordered
> operations are common in languages that need them.

Patch by Daniil Suchkov!

Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D38392

llvm-svn: 315438

IRCE should not apply when the safe iteration range is proved to be empty.
In this case we do unneeded job creating pre/post loops and then never
go to the main loop.

This patch makes IRCE not apply to empty safe ranges, adds test for this
situation and also modifies one of existing tests where it used to happen
slightly.

Reviewed By: anna
Differential Revision: https://reviews.llvm.org/D38577

llvm-svn: 315437

llvm-svn: 315436

llvm-svn: 315435

llvm-svn: 315434

Usually, a function that does symbol lookup takes symbol name as
its first argument. Also, if a function takes a source location hint,
it is usually the last parameter. So the previous parameter order
was counter-intuitive.

llvm-svn: 315433

Because of r314495, DefinedCommon symbols cannot reach to
getSymbolValue function. When they reach the fucntion, they have
already been converted to DefinedRegular symbols.

llvm-svn: 315432

llvm-svn: 315431

"process" was not a good name because everything can be named it.

llvm-svn: 315430

This fixes PR34908. Patch by Alex Crichton!

Differential Revision:  https://reviews.llvm.org/D38765

llvm-svn: 315429