No functionality change.

llvm-svn: 193540

llvm-svn: 193539

llvm-svn: 193538

llvm-svn: 193537

llvm-svn: 193536

an MCExpr, in order to avoid writing an encoded zero value in the immediate
field.

When getUnconditionalBranchTargetOpValue is called with an MCExpr target, we
don't know what the final immediate field value should be. We shouldn't
explicitly set the immediate field to an encoded zero value as zero is encoded
with a non-zero bit pattern. This leads to bits being set that pollute the
final immediate value. The nature of the encoding is such that the polluted
bits only affect very large immediate values, explaining why this hasn't
caused problems earlier.

Fixes <rdar://problem/15155975>.

llvm-svn: 193535

llvm-svn: 193534

llvm-svn: 193527

llvm-svn: 193526

These used to be referenced by the CGI->AWI map (in AsmWriterEmitter), but
stored in a vector local to EmitPrintInstruction. Move the vector to
AsmWriterEmitter too.

llvm-svn: 193525

This commit allows the ARM integrated assembler to parse
and assemble the code with .eabi_attribute, .cpu, and
.fpu directives.

To implement the feature, this commit moves the code from
AttrEmitter to ARMTargetStreamers, and several new test
cases related to cortex-m4, cortex-r5, and cortex-a15 are
added.

Besides, this commit also change the Subtarget->isFPOnlySP()
to Subtarget->hasD16() to match the usage of .fpu directive.

This commit changes the test cases:

* Several .eabi_attribute directives in
  2010-09-29-mc-asm-header-test.ll are removed because the .fpu
  directive already cover the functionality.

* In the Cortex-A15 test case, the value for
  Tag_Advanced_SIMD_arch has be changed from 1 to 2,
  which is more precise.

llvm-svn: 193524

llvm-svn: 193523

useAA significantly improves the handling of vector code that has TBAA
information attached.  It also helps other cases, as shown by the testsuite
changes here.  The only real downside I've seen is that it interferes with
MergeConsecutiveStores.  The problem is that that optimization works top
down, starting at the first store in the chain, and looks for cases where
the chain result is only used by a single related store.  These related
stores don't alias, so useAA will have rewritten all the later stores to
use a different chain input (typically the same one as the first store).

I think the advantages outweigh the disadvantages though, so for now I've
just disabled alias analysis for the unaligned-01.ll test.

llvm-svn: 193521

Making useAA() default to true for SystemZ showed that the combiner alias
analysis wasn't handling volatile accesses.  This hit many of the SystemZ
tests, but I arbitrarily picked one for the purpose of this patch.

llvm-svn: 193518

Most SelectionDAG code drops the TBAA info when creating a new form of a
load and store (e.g. during legalization, or when converting a plain
load to an extending one).  This patch tries to catch all cases where
the TBAA information can legitimately be carried over.

The patch adds alternative forms of getLoad() and getExtLoad() that take
a MachineMemOperand instead of individual fields.  (The corresponding
getTruncStore() already exists.)  The idea is to use the MachineMemOperand
forms when all fields are carried over (size, pointer info, isVolatile,
isNonTemporal, alignment and TBAA info).  If some adjustment is being
made, e.g. to narrow the load, then we still pass the individual fields
but also pass the TBAA info.

llvm-svn: 193517

The error raised by Python varies by platform(!), so let's just catch any
exception and fall back.

Thanks to Sylvestre Ledru for noticing this on a Debian / Python 2.7 system
running code coverage.

llvm-svn: 193516

We can't do this for the general case as saying a GEP with a negative index
doesn't have unsigned wrap isn't valid for negative indices.
  %gep = getelementptr inbounds i32* %p, i64 -1

But an inbounds GEP cannot run past the end of address space. So we check for
the very common case of a positive index and make GEPs derived from that NUW.
Together with Andy's recent non-unit stride work this lets us analyze loops
like

  void foo3(int *a, int *b) {
    for (; a < b; a++) {}
  }

PR12375, PR12376.

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

llvm-svn: 193514

llvm-svn: 193512

llvm-svn: 193511

llvm-svn: 193510

Before I just ported the shell of the pass. I've tried to keep everything
nearly identical to the ARM version. I think it will be very easy to eventually
merge these two and create a new more general pass that other targets can
use. I have some improvements I would like to make to allow pools to 
be shared across functions and some other things. When I'm all done we
can think about making a more general pass. More to be ported but the
basic mechanism works now almost as good as gcc mips16.

llvm-svn: 193509

llvm-svn: 193508

llvm-svn: 193500

llvm-svn: 193499

  - Mark tests as XFAIL:cygming in test/ExecutionEngine/MCJIT/remote.
    Rather to suppress them, I'd like to leave them running as XFAIL.
  - Revert r193472. RecordMemoryManager no longer resolves __main on cygming.

There are a couple of issues.

  - X86 Codegen emits "call __main" in @main for targeting cygming.
    It is useless in JIT. FYI, tests are passing when emitting __main is disabled.
  - Current remote JIT does not resolve any symbols in child context.

FIXME: __main should be disabled, or remote JIT should resolve __main.
llvm-svn: 193498

Patch by Cameron McInally <cameron.mcinally@nyu.edu>

llvm-svn: 193497

llvm-svn: 193496

PR14039

llvm-svn: 193494

llvm-svn: 193493

PR15447

llvm-svn: 193492

PR17608

llvm-svn: 193491

PR17608

llvm-svn: 193490

llvm-svn: 193489

llvm-svn: 193472

so try PATH next. Assume it is sane enough to cover the usual system
bash locations too, but the old list is not good enough for NetBSD.

llvm-svn: 193471

If multiprocessing was requested, detected as available and subsequently failed
to initialize it's worth letting the user know about it before falling back to
threads.

This condition can arise in certain OpenBSD / FreeBSD Python versions.

llvm-svn: 193465

Some versions of Python on the builders seem strict about this.

llvm-svn: 193464

This should be a better fix for lit multiprocessing failures, replacing the
OpenBSD and FreeBSD workarounds in r193413 and r193457.

Reference: http://bugs.python.org/issue3770
llvm-svn: 193463

This patch implements quick look-up for block in loop by maintaining a hash set for blocks.
It improves the efficiency of loop analysis a lot, the biggest improvement could be 5-6%(458.sjeng).
Below are the compilation time for our benchmark in llc before & after the patch.

Benchmark	llc - trunk		llc - patched	
401.bzip2	0.339081	100.00%	0.329657	102.86%
403.gcc		19.853966	100.00%	19.605466	101.27%
429.mcf		0.049823	100.00%	0.048451	102.83%
433.milc	0.514898	100.00%	0.510217	100.92%
444.namd	1.109328	100.00%	1.103481	100.53%
445.gobmk	4.988028	100.00%	4.929114	101.20%
456.hmmer	0.843871	100.00%	0.825865	102.18%
458.sjeng	0.754238	100.00%	0.714095	105.62%
464.h264ref	2.9668		100.00%	2.90612		102.09%
471.omnetpp	4.556533	100.00%	4.511886	100.99%
bitmnp01	0.038168	100.00%	0.0357		106.91%
idctrn01	0.037745	100.00%	0.037332	101.11%
libquake2	3.78689		100.00%	3.76209		100.66%
libquake_	2.251525	100.00%	2.234104	100.78%
linpack		0.033159	100.00%	0.032788	101.13%
matrix01	0.045319	100.00%	0.043497	104.19%
nbench		0.333161	100.00%	0.329799	101.02%
tblook01	0.017863	100.00%	0.017666	101.12%
ttsprk01	0.054337	100.00%	0.053057	102.41%

Reviewer	: Andrew Trick <atrick@apple.com>, Hal Finkel <hfinkel@anl.gov>
Approver	: Andrew Trick <atrick@apple.com>
Test		: Pass make check-all & llvm test-suite

llvm-svn: 193460

I saw the case that 'native' was mis-enabled when x86_64-pc-win32 on x86_64-linux.

FIXME: Consider cases that target can be executed even if host_triple were different from target_triple.
llvm-svn: 193459