This allows 64-bit operations that are truncated to be reduced
to 32-bit ones.

llvm-svn: 204946

llvm-svn: 204945

llvm-svn: 204944

Summary:
No functional change since these predicates are (currently) synonymous.

Extracted from a patch by David Chisnall
His work was sponsored by: DARPA, AFRL

Differential Revision: http://llvm-reviews.chandlerc.com/D3202

llvm-svn: 204943

Previously we would only attach comments to the typedef.

llvm-svn: 204942

cannot be a pointer to the private address space (as clarified
in the OpenCL 1.2 specification).

Patch by Fraser Cormack!

llvm-svn: 204941

Lower SHL_PARTS, SRA_PARTS and SRL_PARTS to perform 128-bit integer shift

Patch by GuanHong Liu.

llvm-svn: 204940

r204379 changed the way the profile runtime gets pulled in, but missed
updating non-Darwin targets.

llvm-svn: 204939

llvm-svn: 204938

While these might make sense for some rule (e.g. break after multi-line
operand), they generally appear ugly and confusing.

Before:
  fffffffffff(R\"x(
  multiline raw string literal xxxxxxxxxxxxxx
  )x\" + bbbbbb)

After:
  fffffffffff(R\"x(
  multiline raw string literal xxxxxxxxxxxxxx
  )x\" +
              bbbbbb)

llvm-svn: 204937

correctly order comments in SourceManager::isBeforeInTranslationUnit() order

Unfortunately, this is not as simple as it was implemented previously, and
actually requires doing a merge sort.

llvm-svn: 204936

This produces valid IR now that llvm rejects aliases to weak aliases and warns
the user that the resolution is not changed if the weak alias is overridden.

llvm-svn: 204935

This adds back r204781.

Original message:

Aliases are just another name for a position in a file. As such, the
regular symbol resolutions are not applied. For example, given

define void @my_func() {
  ret void
}
@my_alias = alias weak void ()* @my_func
@my_alias2 = alias void ()* @my_alias

We produce without this patch:

        .weak   my_alias
my_alias = my_func
        .globl  my_alias2
my_alias2 = my_alias

That is, in the resulting ELF file my_alias, my_func and my_alias are
just 3 names pointing to offset 0 of .text. That is *not* the
semantics of IR linking. For example, linking in a

@my_alias = alias void ()* @other_func

would require the strong my_alias to override the weak one and
my_alias2 would end up pointing to other_func.

There is no way to represent that with aliases being just another
name, so the best solution seems to be to just disallow it, converting
a miscompile into an error.

llvm-svn: 204934

Store the number of clauses and children of OMPExecutableDirective and dynamically compute the locations of corresponding arrays.

http://llvm-reviews.chandlerc.com/D2977

llvm-svn: 204933

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

Differential Revision: http://llvm-reviews.chandlerc.com/D3201

llvm-svn: 204932

llvm-svn: 204931

No functional changes intended.

llvm-svn: 204930

This should make memset_test pass on Mac.

llvm-svn: 204929

The forward declare should be a struct instead of a class (to be consistent with the definition, as well as to silence an MSVC C4099 warning).

llvm-svn: 204928

llvm-svn: 204927

llvm-svn: 204926

llvm-svn: 204925

Summary:
Patch by Robert N. M. Watson
His work was sponsored by: DARPA, AFRL

Small corrections by myself.

CC: theraven, matheusalmeida

Differential Revision: http://llvm-reviews.chandlerc.com/D3199

llvm-svn: 204924

llvm-svn: 204923

[mips] The decision between GOT_DISP and GOT16 for global addresses depends on ABI rather than MIPS64

Summary: No functional change (for supported use cases)

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

Differential Revision: http://llvm-reviews.chandlerc.com/D3191

llvm-svn: 204922

Split the file MipsAsmBackend.cpp in Split the file MipsAsmBackend.cpp and Split the file MipsAsmBackend.h.
Differential Revision: http://llvm-reviews.chandlerc.com/D3134

llvm-svn: 204921

All new elements except the last one initialized to NULL. Ideally, once parsing is complete, all elements should be non-NULL.
To safe-guard BitcodeReader, this patch adds null check for all access to these list.
Patch by Dinesh Dwivedi!

llvm-svn: 204920

llvm-svn: 204919

of MCELFStreamer.

This is so that changes to MipsELFStreamer will automatically propagate through
its subclasses.

No functional changes (MipsELFStreamer has the same functionality of MCELFStreamer
at the moment).

Differential Revision: http://llvm-reviews.chandlerc.com/D3130

llvm-svn: 204918

This allows us to insert some hooks before emitting data into an actual object file.
For example, we can capture the register usage for a translation unit by overriding
the EmitInstruction method. The register usage information is needed to generate
.reginfo and .Mips.options ELF sections.
    
No functional changes.
    
Differential Revision: http://llvm-reviews.chandlerc.com/D3129

llvm-svn: 204917

llvm-svn: 204916

llvm-svn: 204915

llvm-svn: 204914

Clang-format now correctly formats:
  some_type<a * b> v;
  template <bool a, bool b> typename enabled_if<a && b>::type f() {}

llvm-svn: 204913

Transform:
    icmp X+Cst2, Cst
into:
    icmp X, Cst-Cst2
when Cst-Cst2 does not overflow, and the add has nsw.

llvm-svn: 204912

[mips] Stop caching the result of hasMips64(), isABI_O32(), isABI_N32(), and isABI_N64() from MipsSubTarget in MipsTargetLowering

Summary:
The short name is quite convenient so provide an accessor for them instead.

No functional change

Depends on D3177

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

Differential Revision: http://llvm-reviews.chandlerc.com/D3178

llvm-svn: 204911

These don't seem to have any real point. Let's start with
IndexingContext. I can't come up with any conceivable reason to have
many hundereds of thousands of these alive in an address space which
would make the 4x difference in allocated (but unused) memory for the
string scratch buffer a significant memory usage problem.

The EditedSource one is somewhat more surprising. This is an 8x increase
in the memory allocated (but not used) per editted source file. However,
for this to realistically be a problem, you would need to have over half
a million editted source files in a single address space, and even that
would only really have problems on 32-bit Windows where you really only
have 2gb of virtual address space. And what's more important, the fix to
this if it is actually an issue shouldn't be to shrink the allocator's
size, it is to pass a single allocator into *many* edited source file
objects and let them share the memory.

These were the only two uses of custom sized BumpPtrAllocators
(excluding ones in the JIT using a custom allocation strategy) in all of
LLVM, Clang, LLD, LLDB, or Polly. I don't think we actually need this
complexity in the primary BumpPtrAllocator at all and am planning to
remove it.

llvm-svn: 204910

Reviewers: djasper, klimek

Reviewed By: djasper

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3192

llvm-svn: 204909

differences from subsequent diffs, and ease review. Going to be
performing some major surgery to simplify this stuff.

llvm-svn: 204908

rewrite some of them to be more clear.

The terminology being used in our allocators is making me really sad. We
call things slab allocators that aren't at all slab allocators. It is
quite confusing.

llvm-svn: 204907