What we have so far:
- Some clang test failures (these were known already)

- Perf results are mixed, some big regressions
  http://llvm.org/perf/db_default/v4/nts/3844
  http://llvm.org/perf/db_default/v4/nts/3845

  bullet suffers a lot. matmul is interesting: slower scalar code, faster with -vectorize.

- Some dragonegg selfhost bots crash in SROA during selfhost now
  http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.6-self-host-checks/builds/1632
  http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.5-self-host/builds/1891

llvm-svn: 163968

This was only an issue if sse is disabled.

llvm-svn: 163967

llvm-svn: 163966

new one, and add support for running the new pass in that mode and in
that slot of the pass manager. With this the new pass can completely
replace the old one within the pipeline.

The strategy for enabling or disabling the SSAUpdater logic is to do it
by making the requirement of the domtree analysis optional. By default,
it is required and we get the standard mem2reg approach. This is usually
the desired strategy when run in stand-alone situations. Within the
CGSCC pass manager, we disable requiring of the domtree analysis and
consequentially trigger fallback to the SSAUpdater promotion.

In theory this would allow the pass to re-use a domtree if one happened
to be available even when run in a mode that doesn't require it. In
practice, it lets us have a single pass rather than two which was
simpler for me to wrap my head around.

There is a hidden flag to force the use of the SSAUpdater code path for
the purpose of testing. The primary testing strategy is just to run the
existing tests through that path. One notable difference is that it has
custom code to handle lifetime markers, and one of the tests has been
enhanced to exercise that code.

This has survived a bootstrap and the test suite without serious
correctness issues, however my run of the test suite produced *very*
alarming performance numbers. I don't entirely understand or trust them
though, so more investigation is on-going.

To aid my understanding of the performance impact of the new SROA now
that it runs throughout the optimization pipeline, I'm enabling it by
default in this commit, and will disable it again once the LNT bots have
picked up one iteration with it. I want to get those bots (which are
much more stable) to evaluate the impact of the change before I jump to
any conclusions.

NOTE: Several Clang tests will fail because they run -O3 and check the
result's order of output. They'll go back to passing once I disable it
again.

llvm-svn: 163965

C11 7.17's atomic operations. GNU's __atomic_* builtins do allow const-qualified
atomics, though (!!) so don't restrict those.

llvm-svn: 163964

It's not clear if this is working yet on the buildbot.  Reverting until we have
time to investigate.

llvm-svn: 163963

Specifically, this should warn:

  __block block_t a = ^{ a(); };

Furthermore, this case which previously warned now does not, since the value
of 'b' is captured before the assignment occurs:

  block_t b; // not __block
  b = ^{ b(); };

(This will of course warn under -Wuninitialized, as before.)

<rdar://problem/11015883>

llvm-svn: 163962

building on no-Python systems again.

llvm-svn: 163961

use load/store fragments defined in TargetSelectionDAG.td in place of them.
Unaligned loads/stores are either expanded or lowered to target-specific nodes,
so instruction selection should see only aligned load/store nodes.

No changes in functionality.

llvm-svn: 163960

Revert r163878 as it breaks on targets with alternate register names. Such targets do not exist in the main tree so this was not noticed.

llvm-svn: 163959

an environment variable for debugging purposes.

llvm-svn: 163958

the dynamic and static runtime class tables to
construct our isa table.  This is putting the runtime
in contact with unrealized classes, which we need
to deal with in order to get accurate information.
That's the next piece of work.

<rdar://problem/10986023>

llvm-svn: 163957

Patch by Reed Kotler.

llvm-svn: 163956

destination.

Updated previous implementation to fix a case not covered:
// PBI: br i1 %x, TrueDest, BB
// BI:  br i1 %y, TrueDest, FalseDest
The other case was handled correctly.
// PBI: br i1 %x, BB, FalseDest
// BI:  br i1 %y, TrueDest, FalseDest

Also tried to use 64-bit arithmetic instead of APInt with scale to simplify the
computation. Let me know if you have other opinions about this.

llvm-svn: 163954

Collect processor resources from the subtarget defs.

llvm-svn: 163953

Infer SchedClasses from variants defined by the target or subtarget.

llvm-svn: 163952

Collect SchedClasses and SchedRW types from the subtarget defs.

llvm-svn: 163951

llvm-svn: 163950

llvm-svn: 163949

 - The current_pos function is supposed to return all the written bytes, not the
   current position of the underlying stream.
 - This caused tell() to be broken whenever the underlying stream had buffered
   content.

llvm-svn: 163948

llvm-svn: 163947

Fixing a potential crasher where the new C++ synthetic children can return a NULL FrontEnd and cause LLDB to crash. This patch introduces a dummy front-end which the ValueObjectSynthetic can use lacking a real FrontEnd

llvm-svn: 163946

llvm-svn: 163945

Review by Chandler Carruth.

llvm-svn: 163944

<rdar://problem/12304255>

llvm-svn: 163943

case to a conditional branch and when removing dead cases.

llvm-svn: 163942

llvm-svn: 163941

llvm-svn: 163940

bytes of the buffer and not the size of the string, otherwise we
may overwrite the buffer if there is a mismatch between the size
of the string and the CharByteWidth, and assertions are disabled.

The bug where this could occur was fixed in r163931.
Related to rdar://12069503

llvm-svn: 163939

llvm-svn: 163938

llvm-svn: 163937

llvm-svn: 163936

llvm-svn: 163935

llvm-svn: 163934

llvm-svn: 163933

llvm-svn: 163932

to the target info.

Related to rdar://12069503.

llvm-svn: 163931

llvm-svn: 163930

llvm-svn: 163929

lit config.

llvm-svn: 163928