APIs and replace it and numerous booleans with an option struct.

The critical edge splitting API has a really large surface of flags and
so it seems worth burning a small option struct / builder. This struct
can be constructed with the various preserved analyses and then flags
can be flipped in a builder style.

The various users are now responsible for directly passing along their
analysis information. This should be enough for the critical edge
splitting to work cleanly with the new pass manager as well.

This API is still pretty crufty and could be cleaned up a lot, but I've
focused on this change just threading an option struct rather than
a pass through the API.

llvm-svn: 226456

It became invalid after signature changes.

llvm-svn: 226455

Crashing input:
  /\
  / comment

llvm-svn: 226454

InternalAlloc is quite complex and its behavior may depend on the values of
flags. As such, it should not be used while parsing flags.

Sadly, LowLevelAlloc does not support deallocation of memory.

llvm-svn: 226453

llvm-svn: 226452

Previously crashing input:
  void f(
  #if A
      );
  #else
  #endif

llvm-svn: 226451

Input "a<," made clang-format crash.

llvm-svn: 226450

llvm-svn: 226449

llvm-svn: 226448

llvm-svn: 226447

This assert would trigger on:
  #d , = }

llvm-svn: 226446

Emacs functions by default use character positions; convert characters
to offsets when handing parameters to clang-format and convert byte
offsets we get from clang-format back to character positions.
Reworked the code a bit so the 0-based to 1-based offset calculations
are done in the same place where we do the multi-byte to offset mapping.

llvm-svn: 226445

test. Do that after we suppress the warnings for unknown pragmas as this
warning flag is quite new in Clang and so old Clang's would warn all the
time on this file.

llvm-svn: 226444

we can while splitting critical edges.

The only code which called this and didn't require simplified loops to
be preserved is polly, and the code behaves correctly there anyways.
Without this change, it becomes really hard to share this code with the
new pass manager where things like preserving loop simplify form don't
make any sense.

If anyone discovers this code behaving incorrectly, what it *should* be
testing for is whether the loops it needs to be in simplified form are
in fact in that form. It should always be trying to preserve that form
when it exists.

llvm-svn: 226443

It shouldn't have been removed, the code which replaced it didn't cover
this case.

llvm-svn: 226442

llvm-svn: 226441

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

llvm-svn: 226440

In case of blocks with many memory-accessing instructions, alias checking can take lot of time
(because calculating the memory dependencies has quadratic complexity).
I chose a limit which resulted in no changes when running the benchmarks.

llvm-svn: 226439

And handle help=1 in standalone LSan.

llvm-svn: 226438

llvm-svn: 226437

Things that are OK:
  extern int var1 __attribute((alias("v1")));
  static int var2 __attribute((alias("v2")));

Things that are not OK:
  int var3 __attribute((alias("v3")));
  extern int var4 __attribute((alias("v4"))) = 4;

We choose to accpet:
  struct S { static int var5 __attribute((alias("v5"))); };

  This code causes assertion failues in GCC 4.8 and ICC 13.0.1, we have
  no reason to reject it.

This partially fixes PR22217.

llvm-svn: 226436

llvm-svn: 226435

We don't need to exclude patchpoints from the implicit r2 dependence in
FastISel because it is added as an implicit operand and, thus, should not
confuse that StackMap code.

By inspection / no test case.

llvm-svn: 226434

This fixes PR21792.

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

llvm-svn: 226433

Our PPC64 ELF V2 call lowering logic added r2 as an operand to all direct call
instructions in order to represent the dependency on the TOC base pointer
value. Restricting this to ELF V2, however, does not seem to make sense: calls
under ELF V1 have the same dependence, and indirect calls have an r2 dependence
just as direct ones. Make sure the dependence is noted for all calls under both
ELF V1 and ELF V2.

llvm-svn: 226432

[X86] Change AVX512 intrinsics to take a 8-bit immediate for the comparision kind instead of a 32-bit immediate. This matches an equivalent change in llvm.

llvm-svn: 226431

[x86] Change AVX512 intrinsics to take a 8-bit immediate for the comparision kind instead of a 32-bit immediate. This better aligns with the emitted instruction. It also matches SSE and AVX1 equivalents. Also add auto upgrade support.

llvm-svn: 226430

The copyprivate clause must not be used with the nowait clause in single
directive.

llvm-svn: 226429

[tinyptrvector] Add in a MutableArrayRef implicit conversion operator to complement the ArrayRef implicit conversion operator.

llvm-svn: 226428

This should fix the LLDB build since that change.

llvm-svn: 226427

SplitLandingPadPredecessors and remove the Pass argument from its
interface.

Another step to the utilities being usable with both old and new pass
managers.

llvm-svn: 226426

llvm-svn: 226425

There is no reason for this state to be exposed as public. The single element
constructor was superfulous in light of the single element ArrayRef
constructor.

llvm-svn: 226424

Warn on inaccessible direct base

llvm-svn: 226423

llvm-svn: 226422

[x86] Mark that the AVX-512 cmpps/cmppd builtins need an ICE for the comparison immediate. This requires converting to a macro in the header file.

llvm-svn: 226421

lets 'ninja check-polly' pass for me with a lib64 build of LLVM.

I've not updated the standalone side as I don't use it and don't have an
easy way to test any changes I've made there. I mostly wanted to be able
to actually run Polly's tests when I update its use of LLVM's APIs
during my refactorings on the (very unlikely) off chance that I make
a change which compiles but does the wrong thing.

llvm-svn: 226420

llvm-svn: 226419

llvm-svn: 226418

llvm-svn: 226417