Updating dominators for exit-blocks of the unrolled loops is not enough,
as shown in PR27157. The proper way is to update dominators for all
dominance-children of original loop blocks.

llvm-svn: 265605

This will be used by the register bank select pass to assign register banks
for generic virtual registers.

This was originally committed as r265573 but broke at least one windows bot.
The problem with the windows bot was that it was using a copy constructor for
the InstructionMappings class and could not synthesize it. Actually, the fact
that this class is not copy constructable is expected and the compiler should
use the move assignment constructor. Marking the problematic assignment
explicitly as using the move constructor has its own problems.

Indeed, with recent clang we get a warning that we may prevent the elision of
the copy by the compiler. A proper fix for both compilers would be to change the
API of getPossibleInstrMapping to take a InstructionMappings as input/output
parameter. This does not feel natural and since GISel is not used on windows
yet, I chose to workaround the problem by not compiling the problematic code on
windows.

llvm-svn: 265604

llvm-svn: 265603

Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 barring a small question that's still open.

The code currently plays fast and loose with the AtomicOrdering
enum. Using an enum class is one step towards tightening things. I later
also want to tighten related enums, such as clang's
AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI'
enum).

This change touches a few lines of code which can be improved later, I'd
like to keep it as NFC for now as it's already quite complex. I have
related changes for clang.

As a follow-up I'll add:
  bool operator<(AtomicOrdering, AtomicOrdering) = delete;
  bool operator>(AtomicOrdering, AtomicOrdering) = delete;
  bool operator<=(AtomicOrdering, AtomicOrdering) = delete;
  bool operator>=(AtomicOrdering, AtomicOrdering) = delete;
This is separate so that clang and LLVM changes don't need to be in sync.

Reviewers: jyknight, reames

Subscribers: jyknight, llvm-commits

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

llvm-svn: 265602

This reverts r265359.

It breaks
- llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
- llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast

Failing Tests (5):
    Clang :: FixIt/fixit-errors.c
    Clang :: Preprocessor/init.c
    Clang :: Sema/attr-deprecated.c
    Clang :: Sema/nullability.c
    Clang :: SemaObjC/objcbridge-attribute-arc.m

llvm-svn: 265601

This patch add a base script tokenizer class to decouple parsing from
linker script handling.  The idea is to use this base class on dynamic
list parsing (--dynamic-list option). No functionality added.

llvm-svn: 265600

llvm-svn: 265599

llvm-svn: 265598

Fixes https://llvm.org/bugs/show_bug.cgi?id=27186

Patch reviewed by Richard Smith.

llvm-svn: 265597

NFC.

llvm-svn: 265596

`UNIX` is for the target.

llvm-svn: 265595

llvm-svn: 265594

http://reviews.llvm.org/D18405

When the integer value loaded is never used directly as integer we should use VSX 
or Floating Point Facility integer loads and avoid extra direct move

llvm-svn: 265593

Turns out it was there mostly to prevent Clang asking people to report a bug.
This time we report something to Clang's real diagnostics handler so that it
exits with something approximating a real error and tidies up after itself.

llvm-svn: 265592

llvm-svn: 265591

GCC reports "missing terminating ' character", even when it's being
skipped by preprocessing.

llvm-svn: 265590

This makes it possible to distinguish between mesa shaders
and other kernels even in the presence of compute shaders.

Patch By: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>

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

llvm-svn: 265589

Show that in addition to handling empty .eh_frame, it is merged with any
regular .eh_frame.

llvm-svn: 265588

instruction on a register bank. This will be used by the register bank select
pass to assign register banks for generic virtual registers." and the follow-on
commits while I find out a way to fix the win7 bot:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/19882

This reverts commit r265578, r265581, r265584, and r265585.

llvm-svn: 265587

r265515, this time with the correct fix. file inside DISubprogram is not
mandatory.

llvm-svn: 265586

The default constructor now uses the regular constructor and the assert
is not valid anymore.

llvm-svn: 265585

default constructor, instead of relying on the default constructor of
unique_ptr.

Second attempt at fixing the windows bot.

llvm-svn: 265584

llvm-svn: 265583

helper class.

The default constructor creates invalid (isValid() == false) instances
and may be used to communicate that a mapping was not found.

llvm-svn: 265581

Approved by:	ruiu
Differential Revision:	http://reviews.llvm.org/D18835

llvm-svn: 265580

Thanks to Rafael for the suggestion!

llvm-svn: 265579

The previous method to get the size was too simple and could fail for
physical registers.

llvm-svn: 265578

Use a DenseSet instead of a DenseMap for constants in LLVMContextImpl.
Last time I looked at this was some time before r223588, when
DenseSet<V> had no advantage over DenseMap<V,char>.  After r223588,
there's a 50% memory savings.

This is all mechanical.  There were little bits of missing API from
DenseSet so I added the trivial implementations:

  - iterator::operator++(int)
  - template <class LookupKeyT> insert_as(ValueTy, LookupKeyT)

There should be no functionality change, just reduced memory consumption
(this wasn't on a profile or anything; just a cleanup I stumbled on).

llvm-svn: 265577

The MDStringCache doesn't need to be explicitly cleared before
destruction.  The destructor handles it at least as efficiently.

llvm-svn: 265576

Similar to r265462, TLS related relocations aren't marked as relative,
meaning that we end up generating R_AARCH64_RELATIVE relocations for
them. This change adds TLS relocations that I've seen on my system. With
this patch applied CloudABI's unit testing binary now passes on aarch64.

Approved by:	ruiu
Differential Revision:	http://reviews.llvm.org/D18816

llvm-svn: 265575

This should be TableGen'ed at some point.

llvm-svn: 265574

This will be used by the register bank select pass to assign register banks
for generic virtual registers.

llvm-svn: 265573

`source_filename` was introduced as a keyword in SVN r264884, but the syntax
file was not updated.

llvm-svn: 265572

Patch by Erik Pilkington!

llvm-svn: 265571

when GISel is not built.
The positive side effects are:
- We do not have to define dummy implementation
- We do not have to do weird gymnastic to avoid like issues (like
  missing constructor or vtable for the base classes)

llvm-svn: 265570

Summary: See LLVM change D18775 for details, this change depends on it.

Reviewers: jyknight, reames

Subscribers: cfe-commits

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

llvm-svn: 265569

Rework the access to GlobalISel APIs to contain how much of
the APIs we need to access for the final executable to build when
GlobalISel is not built.

This prevents massive usage of ifdefs in various places. Now, all the
GlobalISel ifdefs will be happing only in AArch64TargetMachine.cpp.

llvm-svn: 265567

Suggested by Dave Blaikie in review of r265447. Thanks Dave!

llvm-svn: 265566

llvm-svn: 265565

ASTWriter."), reverted in r265526, with a fix for an iterator invalidation bug
(thanks, MSan!).

llvm-svn: 265564