llvm-svn: 266182

+ updated formatting

llvm-svn: 266181

Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header".
This fixes the modules build.

Differential revision: http://reviews.llvm.org/D18954
Reviewers: Richard Smith, Vassil Vassilev.

llvm-svn: 266180

[mips][microMIPS] Add CodeGen support for DIV, MOD, DIVU, MODU, DDIV, DMOD, DDIVU and DMODU instructions
Differential Revision: http://reviews.llvm.org/D17137

This patch was reverted after the revertion of dependant patch http://reviews.llvm.org/D17068.
There was the problem with test-suite failure.
The problem is hopefully solved with dependant patch so this patch is commited again.

llvm-svn: 266179

llvm-svn: 266178

llvm-svn: 266177

[modules] Add some missing blockinfo records. No functionality change except to llvm-bcanalyzer output.

llvm-svn: 266176

Remove an ad-hoc transform in InstCombine and replace it with more
general machinery (ValueTracking, InstructionSimplify and VectorUtils).

This fixes PR27332.

llvm-svn: 266175

It is now only doing the update to the llvm.compiler_used global.
The client has to call separately the internalization stage.
Hopefully the code is simpler to understand this way.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266174

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266173

LTOInternalize: Use a StringSet instead of a sorted vector and a binary search query for each function

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266172

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

This changes contains fix for failing test-suite. So, this patch should hopefully work now.

llvm-svn: 266171

This is not really related to internalization per se.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266170

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266169

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266168

Refactor the InternalizePass into a helper class, and expose it through a public free function (NFC)

There is really no reason to require to instanciate a pass manager to
internalize.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266167

[PPC64][VSX] Add a couple of new data types for vec_vsx_ld and vec_vsx_st intrinsics and fix incorrect testcases with minor refactoring

New added data types:
  vector double vec_vsx_ld (int, const double *);
  vector float vec_vsx_ld (int, const float *);
  vector bool short vec_vsx_ld (int, const vector bool short *);
  vector bool int vec_vsx_ld (int, const vector bool int *);
  vector signed int vec_vsx_ld (int, const signed int *);
  vector unsigned int vec_vsx_ld (int, const unsigned int *);

  void vec_vsx_st (vector double, int, double *);
  void vec_vsx_st (vector float, int, float *);
  void vec_vsx_st (vector bool short, int, vector bool short *);
  void vec_vsx_st (vector bool short, int, signed short *);
  void vec_vsx_st (vector bool short, int, unsigned short *);
  void vec_vsx_st (vector bool int, int, vector bool int *);
  void vec_vsx_st (vector bool int, int, signed int *);
  void vec_vsx_st (vector bool int, int, unsigned int *);

Also fix testcases which use non-vector argument version of vec_vsx_ld or
vec_vsx_st, but pass incorrect parameter.

llvm-svn: 266166

will not exceed the bounds of their Section.  This is addressing a
problem where a file had a large space between two sections that
were not used by this module - the last symbol in the text section
had an enormous size because the distance between that and the first
symbol in the data section were used to compute the size.

http://reviews.llvm.org/D19004
<rdar://problem/25227945> 

llvm-svn: 266165

llvm-svn: 266164

This will save a bunch of copies / initialization of intermediate
datastructure, and (hopefully) simplify the code.

This also abstract the symbol preservation mechanism outside of the
Internalization pass into the client code, which is not forced
to keep a map of strings for instance (ThinLTO will prefere hashes).

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266163

two fixes with one about error verify-regalloc reported, and
another about live range update of phi after rematerialization.

r265547:
Replace analyzeSiblingValues with new algorithm to fix its compile
time issue. The patch is to solve PR17409 and its duplicates.

analyzeSiblingValues is a N x N complexity algorithm where N is
the number of siblings generated by reg splitting. Although it
causes siginificant compile time issue when N is large, it is also
important for performance since it removes redundent spills and
enables rematerialization.

To solve the compile time issue, the patch removes analyzeSiblingValues
and replaces it with lower cost alternatives containing two parts. The
first part creates a new spill hoisting method in postOptimization of
register allocation. It does spill hoisting at once after all the spills
are generated instead of inside every instance of selectOrSplit. The
second part queries the define expr of the original register for
rematerializaiton and keep it always available during register allocation
even if it is already dead. It deletes those dead instructions only in
postOptimization. With the two parts in the patch, it can remove
analyzeSiblingValues without sacrificing performance.

Patches on top of r265547:
r265610 "Fix the compare-clang diff error introduced by r265547."
r265639 "Fix the sanitizer bootstrap error in r265547."
r265657 "InlineSpiller.cpp: Escap \@ in r265547. [-Wdocumentation]"

Differential Revision: http://reviews.llvm.org/D15302
Differential Revision: http://reviews.llvm.org/D18934
Differential Revision: http://reviews.llvm.org/D18935
Differential Revision: http://reviews.llvm.org/D18936

llvm-svn: 266162

We need to ensure that the address of an undefined weak symbol evaluates to
zero. We were getting this right for non-PIC executables (where the symbol
can be evaluated directly) and for DSOs (where we emit a symbolic relocation
for these symbols, as they are preemptible). But we weren't getting it right
for PIEs. Probably the simplest way to ensure that these symbols evaluate
to zero is by not creating a relocation in .got for them.

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

llvm-svn: 266161

[modules] Refactor handling of cases where we write an offset to a prior record into the bitstream and simplify a little, in preparation for doing this in more cases.

llvm-svn: 266160

Fix FunctionImport export list computation: need to take a reference to a map entry to actually modify it

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266159

With this patch we use the first scan over the relocations to remember
the information we found about them: will them be relaxed, will a plt be
used, etc.

With that the actual relocation application becomes much simpler. That
is particularly true for the interfaces in Target.h.

This unfortunately means that we now do two passes over relocations for
non SHF_ALLOC sections. I think this can be solved by factoring out the
code that scans a single relocation. It can then be used both as a scan
that record info and for a dedicated direct relocation of non SHF_ALLOC
sections.

I also think it is possible to reduce the number of enum values by
representing a target with just an OutputSection and an offset (which
can be from the start or end).

This should unblock adding features like relocation optimizations.

llvm-svn: 266158

Treat a _Nonnull ivar that is nil as an invariant violation in a similar
fashion to how a nil _Nonnull parameter is treated as a precondition violation.

This avoids warning on defensive returns of nil on defensive internal
checks, such as the following common idiom:

@class InternalImplementation
@interface PublicClass {
  InternalImplementation * _Nonnull _internal;
}
-(id _Nonnull)foo;
@end

@implementation PublicClass
-(id _Nonnull)foo {
  if (!_internal)
    return nil; // no-warning

  return [_internal foo];
}
@end

rdar://problem/24485171

llvm-svn: 266157

Initialization of m0 is emitted for each LDS operation, so
every block with LDS usage ends up with one. MachineLICM
used to fail to hoist this out of the loop, so every loop
iteration with LDS usage in it would re-initialize it.

This seems to be fixed now, so add a test to make sure that
it stays this way.

llvm-svn: 266156

llvm-svn: 266155

llvm-svn: 266154

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266153

Summary:
It seems like this was broken in r252327.  I thought we had test cases
for this, but it's really hard to tirgger spills of this exact register
size since they aren't used very much.

Reviewers: arsenm, nhaehnle

Subscribers: nhaehnle, arsenm, llvm-commits

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

llvm-svn: 266152

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266151

This state is no longer useful and not guaranteed to be valid in later
codegen passes. For example, see the added test, which would print a
savepoint of %bb.-1 without this change, and crashes with a
use-after-free error under ASan if you apply the recycling allocator
patch from llvm.org/PR26808.

llvm-svn: 266150

llvm-svn: 266149

This bug was introduced with:
http://reviews.llvm.org/rL262269

AVX masked loads are specified to set vector lanes to zero when the high bit of the mask
element for that lane is zero:
"If the mask is 0, the corresponding data element is set to zero in the load form of these
instructions, and unmodified in the store form." --Intel manual

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

llvm-svn: 266148

exiting the for-in loop.

This commit fixes a bug where EmitObjCForCollectionStmt didn't pop
cleanups for captures.

For example, in the following for-in loop, a block which captures self
is passed to foo1:

for (id x in [self foo1:^{ use(self); }]) {
  use(x);
  break;
}

Previously, the code in EmitObjCForCollectionStmt wouldn't pop the
cleanup for the captured self before exiting the loop, which caused
code-gen to generate an IR in which objc_release was called twice on
the captured self.

This commit fixes the bug by entering a RunCleanupsScope before the
loop condition is evaluated and forcing its cleanup before exiting the
loop.

rdar://problem/16865751

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

llvm-svn: 266147

rdar://24711047

llvm-svn: 266146

When run with the multiprocess test runner, the getchar() trick doesn't work, so ninja check-lldb would fail on this test, but running the test directly worked fine.

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

llvm-svn: 266145

llvm-svn: 266144

llvm-svn: 266143