This makes LLVM emit the same signature regardless of host and target endianess.

llvm-svn: 187304

do in the SDag when lowering references to the GOT: use
ARMConstantPoolSymbol rather than creating a dummy global variable. The
computation of the alignment still feels weird (it uses IR types and
datalayout) but it preserves the exact previous behavior. This change
fixes the memory leak of the global variable detected on the valgrind
leak checking bot.

Thanks to Benjamin Kramer for pointing me at ARMConstantPoolSymbol to
handle this use case.

llvm-svn: 187303

me) should start watching this bot more as its catching lots of bugs.

The fix here is to not construct the global if we aren't going to need
it. That's cheaper anyways, and globals have highly predictable types in
practice. I've added an assert to catch skew between our manual testing
of the type and the actual type just for paranoia's sake.

Note that this pattern is actually fine in most globals because when you
build a global with a module it automatically is moved to be owned by
that module. But here, we're in isel and don't really want to do that.
The solution of not creating a global is simpler anyways.

llvm-svn: 187302

There doesn't appear to be any reason to put this variable on the heap.
I'm suspicious of the LexicalScope above that we stuff in a map and then
delete afterward, but I'm just trying to get the valgrind bot clean.

llvm-svn: 187301

than once, and the second time through we leaked memory. Found thanks to
the vg-leak bot, but I can't locally reproduce it with valgrind. The
debugger confirms that it is in fact leaking here.

This whole code is totally gross. Why is initialize being called on each
runOnFunction??? Why aren't these OwningPtr<>s, and why aren't their
lifetimes better defined? Anyways, this is just a surgical change to
help out the leak checking bots.

llvm-svn: 187299

their being optimized out in debug mode. Realistically, this just isn't
going to be the slow part anyways. This also fixes unused variable
warnings that are breaking LLD build bots. =/ I didn't see these at
first, and kept losing track of the fact that they were broken.

llvm-svn: 187297

analysis of the alloca. We don't need to visit all the users twice for
this. We build up a kill list during the analysis and then just process
it afterward. This recovers the tiny bit of performance lost by moving
to the visitor based analysis system as it removes one entire use-list
walk from mem2reg. In some cases, this is now faster than mem2reg was
previously.

llvm-svn: 187296

llvm-svn: 187293

llvm-svn: 187291

llvm-svn: 187286

Also always add DIType, DISubprogram and DIGlobalVariable to the list
in DebugInfoFinder without checking them, so we can verify them later
on.

llvm-svn: 187285

llvm-svn: 187284

Adds unit tests for it too.

Split BasicBlockUtils into an analysis-half and a transforms-half, and put the
analysis bits into a new Analysis/CFG.{h,cpp}. Promote isPotentiallyReachable
into llvm::isPotentiallyReachable and move it into Analysis/CFG.

llvm-svn: 187283

llvm-svn: 187279

Merge consecutive if-regions if they contain identical statements.
Both transformations reduce number of branches.  The transformation
is guarded by a target-hook, and is currently enabled only for +R600,
but the correctness has been tested on X86 target using a variety of
CPU benchmarks.

Patch by: Mei Ye

llvm-svn: 187278

llvm-svn: 187271

llvm-svn: 187268

SLP Vectorier:  Don't vectorize really short chains because they are already handled by the SelectionDAG store-vectorizer, which does a better job in deciding when to vectorize.

llvm-svn: 187267

SLP Vectorizer: Disable the vectorization of non power of two chains, such as <3 x float>, because we dont have a good cost model for these types.

llvm-svn: 187265

This change makes test with RUN lines like
RUN: opt ... | FileCheck

fail if opt fails, even if it prints what FileCheck wants. Enabling this
found some interesting cases of broken tests that were not being noticed
because opt (or some other tool) was crashing late.

Pipefail is used when the shell supports it or when using the internal
python based tester.

llvm-svn: 187261

llvm-svn: 187260

This reverts commit r187248. It broke many bots.

llvm-svn: 187254

llvm-svn: 187253

llvm-svn: 187252

llvm-svn: 187250

also worthwhile for it to look through FP extensions and truncations, whose
application commutes with fneg.

llvm-svn: 187249

Both GCC and LLVM will implicitly define __ppc__ and __powerpc__ for
all PowerPC targets, whether 32- or 64-bit.  They will both implicitly
define __ppc64__ and __powerpc64__ for 64-bit PowerPC targets, and not
for 32-bit targets.  We cannot be sure that all other possible
compilers used to compile Clang/LLVM define both __ppc__ and
__powerpc__, for example, so it is best to check for both when relying
on either inside the Clang/LLVM code base.

This patch makes sure we always check for both variants.  In addition,
it fixes one unnecessary check in lib/Target/PowerPC/PPCJITInfo.cpp.
(At least one of __ppc__ and __powerpc__ should always be defined when
compiling for a PowerPC target, no matter which compiler is used, so
testing for them is unnecessary.)

There are some places in the compiler that check for other variants,
like __POWERPC__ and _POWER, and I have left those in place.  There is
no need to add them elsewhere.  This seems to be in Apple-specific
code, and I won't take a chance on breaking it.

There is no intended change in behavior; thus, no test cases are
added.

llvm-svn: 187248

llvm-svn: 187247

llvm-svn: 187245

Patch by Sasa Stankovic.

llvm-svn: 187244

register operands.

llvm-svn: 187242

Thanks to Han Finkel for noticing it.

llvm-svn: 187241

operands.

llvm-svn: 187238

We used to call Verify before adding DICompileUnit to the list, and now we
remove the check and always add DICompileUnit to the list in DebugInfoFinder,
so we can verify them later on.

llvm-svn: 187237

llvm-svn: 187234

to have register FCC0 (the first floating point condition code register) in
their Uses/Defs list.

No intended functionality change.

llvm-svn: 187233

needed. The generic method printOperand will do.

No functionality change.

llvm-svn: 187231

instructions "beqz", "bnez" and "move", when possible.

beq $2, $zero, $L1 => beqz $2, $L1
bne $2, $zero, $L1 => bnez $2, $L1
or  $2, $3, $zero  => move $2, $3

llvm-svn: 187229

llvm-svn: 187226

llvm-svn: 187225