llvm-svn: 176409

This adds minimalistic support for PHI nodes to llvm.objectsize() evaluation

fingers crossed so that it does break clang boostrap again..

llvm-svn: 176408

this is similar to getObjectSize(), but doesnt subtract the offset
tweak the BasicAA code accordingly (per PR14988)

llvm-svn: 176407

llvm-svn: 176406

in a core file if it didn't start at the beginning of a memory segment.
I added more sophisticated kernel location code to DynamicLoaderDarwinKernel
and removed the simple one in ProcessMachCore.  Unfortunately the kernel
DynamicLoader doesn't get a chance to search around in memory unless there's
a hint that this might be a kernel debug session.  It was easy ot make the
kernel location code static in DynamicLoaderDarwinKernel and call it from
ProcessMachCore on the start of the session, so that's what I did.
<rdar://problem/13326647> 

llvm-svn: 176405

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

llvm-svn: 176404

This matters for example in following matrix multiply:

int **mmult(int rows, int cols, int **m1, int **m2, int **m3) {
  int i, j, k, val;
  for (i=0; i<rows; i++) {
    for (j=0; j<cols; j++) {
      val = 0;
      for (k=0; k<cols; k++) {
        val += m1[i][k] * m2[k][j];
      }
      m3[i][j] = val;
    }
  }
  return(m3);
}

Taken from the test-suite benchmark Shootout.

We estimate the cost of the multiply to be 2 while we generate 9 instructions
for it and end up being quite a bit slower than the scalar version (48% on my
machine).

Also, properly differentiate between avx1 and avx2. On avx-1 we still split the
vector into 2 128bits and handle the subvector muls like above with 9
instructions.
Only on avx-2 will we have a cost of 9 for v4i64.

I changed the test case in test/Transforms/LoopVectorize/X86/avx1.ll to use an
add instead of a mul because with a mul we now no longer vectorize. I did
verify that the mul would be indeed more expensive when vectorized with 3
kernels:

for (i ...)
   r += a[i] * 3;
for (i ...)
  m1[i] = m1[i] * 3; // This matches the test case in avx1.ll
and a matrix multiply.

In each case the vectorized version was considerably slower.

radar://13304919

llvm-svn: 176403

Inlining brought a few "null pointer use" false positives, which occur because
the callee defensively checks if a pointer is NULL, whereas the caller knows
that the pointer cannot be NULL in the context of the given call.

This is a first attempt to silence these warnings by tracking the symbolic value
along the execution path in the BugReporter. The new visitor finds the node
in which the symbol was first constrained to NULL. If the node belongs to
a function on the active stack, the warning is reported, otherwise, it is
suppressed.

There are several areas for follow up work, for example:
 - How do we differentiate the cases where the first check is followed by
another one, which does happen on the active stack?

Also, this only silences a fraction of null pointer use warnings. For example, it
does not do anything for the cases where NULL was assigned inside a callee.

llvm-svn: 176402

command source fidelity. // rdar://13066276

llvm-svn: 176401

llvm-svn: 176400

The LoopVectorizer often runs multiple times on the same function due to inlining.
When this happens the loop vectorizer often vectorizes the same loops multiple times, increasing code size and adding unneeded branches.
With this patch, the vectorizer during vectorization puts metadata on scalar loops and marks them as 'already vectorized' so that it knows to ignore them when it sees them a second time.

PR14448.

llvm-svn: 176399

llvm-svn: 176398

llvm-svn: 176397

Previously we relied on it being included by config-ix.cmake.

llvm-svn: 176396

This reverts commit aac7922b8fe7ae733d3fe6697e6789fd730315dc. I am reverting the
commit since it broke the phase 1 public buildbot for a few hours.

http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RA/builds/2137

llvm-svn: 176394

In LLVM, -pedantic is not set unless LLVM_ENABLE_PEDANTIC is set.
However, Clang's CMakeLists.txt unilaterally adds -pedantic to the run
line, so we need to disable -Wnested-anon-types explicitly.

llvm-svn: 176393

Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.

<rdar://problem/11319574>
<rdar://problem/9329275>

llvm-svn: 176392

llvm-svn: 176391

Fix the way resources are counted. I'm taking some time to cleanup the
way MachineScheduler handles in-order machine resources. Eventually
we'll need more PPC/Atom test cases in tree.

llvm-svn: 176390

See http://clang-analyzer.llvm.org/release_notes.html for what's new
in this build.

llvm-svn: 176389

Previously we were assuming that we'd never ask for the sub-region bindings
of a bitfield, since a bitfield cannot have subregions. However,
unification of code paths has made that assumption invalid. While we could
take advantage of this by just checking for the single possible binding,
it's probably better to do the right thing, so that if/when we someday
support unions we'll do the right thing there, too.

This fixes a handful of false positives in analyzing LLVM.

<rdar://problem/13325522>

llvm-svn: 176388

in AST for source fidelity and use it in diagnostics 
to refer to the original format. // rdar://13066276

llvm-svn: 176387

The sys::fs::is_directory() check is unnecessary because, if the filename is
a directory, the function will fail anyway with the same error code returned.
Remove the check to avoid an unnecessary stat call.

Someone needs to review on windows and see if the check is necessary there or not.

llvm-svn: 176386

Checking to see if svn notifications also use correct address now.

llvm-svn: 176385

This patch eliminates the need to emit a constant move instruction when this
pattern is matched:

(select (setgt a, Constant), T, F)

The pattern above effectively turns into this:

(conditional-move (setlt a, Constant + 1), F, T)

llvm-svn: 176384

These all appear in comments or (ironically) diagnostics output.

llvm-svn: 176383

llvm-svn: 176382

Also removed the comments of "should produce..." because they completely
don't match the actually produced output.

llvm-svn: 176381

llvm-svn: 176380

extra/test/cpp11-migrate/Makefile was using the same tmp file for generating
lit.site.cfg for two different directories. Parallelism caused conflicts so now
using differently named temp files.

llvm-svn: 176379

llvm-svn: 176378

detail.

The was this test was written, it was relying on an implementation detail
(fixups) and hence was very brittle (relying, among other things, on the
exact ordering of statistics printed by MC).

The test was rewritten to check a more observable output difference. While it
doesn't cover 100% of the things the original test covered, it's a good
practice to write regression tests this way. If we want to check that
internal details and invariants hold, such tests should be expressed as unit
tests.

llvm-svn: 176377

Previously we would check the syntax of the file before we transform
it, but that's redundant since it'll be checked as part of the
transformation. Remove that check completely.

We also had an unconditional syntax check after transforming. This
is only really useful to debug cpp11-migrate, since users will end
up compiling the transformed source anyways, and the transformations
*should* never introduce a failure. Made this an option, accessible
via "-final-syntax-check".

Resolves PR 15380.

llvm-svn: 176376

and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since
if that does anything that requires the API lock it may deadlock against whoever is
running the Process::Destroy.

<rdar://problem/13308627>

llvm-svn: 176375

The make (all) target takes care of creating lit configs and auto-generating
tests. The problem with the original 'lit.site.cfg' target is it's not
recursive and doesn't fully create everything necessary for testing
clang-tools-extra.

llvm-svn: 176374

Autoconf make (all) now properly recurses from tools/extra/Makefile into
tools/extra/test/Makefile and tools/extra/test/cpp11-migrate/Makefile. The
'all' target is responsible for creating lit config files and autogenerating
tests. Subsequent 'check-all' targets will properly work.

Re-enabling UseAuto/iterator.cpp test.

General clean-up of clang-tools-extra makefiles; removing dead targets and
removing duplicated pieces of llvm/Makefile.rules.

llvm-svn: 176373

This moves the actual replacement code into a separate
function. There is still a bit of code duplication to
go from macros to expansion areas, but that code will
need to be fixed anyways to resolve bugs around macro
replacement.

Reviewed by: Tareq Siraj, Edwin Vane

llvm-svn: 176372

Most map types have an operator[] that inserts a new element if the key
isn't found, then returns a reference to the value slot so that you can
assign into it. However, if the value type is a pointer, it will be
initialized to null. This is usually no problem.

However, if the user /knows/ the map contains a value for a particular key,
they may just use it immediately:

   // From ClangSACheckersEmitter.cpp
   recordGroupMap[group]->Checkers

In this case the analyzer reports a null dereference on the path where the
key is not in the map, even though the user knows that path is impossible
here. They could silence the warning by adding an assertion, but that means
splitting up the expression and introducing a local variable. (Note that
the analyzer has no way of knowing that recordGroupMap[group] will return
the same reference if called twice in a row!)

We already have logic that says a null dereference has a high chance of
being a false positive if the null came from an inlined function. This
patch simply extends that to references whose rvalues are null as well,
silencing several false positives in LLVM.

<rdar://problem/13239854>

llvm-svn: 176371

llvm-svn: 176370

- These tests wont't crash on trunk but would be better to add them so that
  they don't break again in the future.

llvm-svn: 176369