llvm-svn: 182220

[Sparc] Rearrange integer registers' allocation order so that register allocator will use I and G registers before using L and O registers.

Also, enable registers %g2-%g4 to be used in application and %g5 in 64 bit mode.

llvm-svn: 182219

llvm-svn: 182218

llvm-svn: 182217

llvm-svn: 182216

Other operating systems, including FreeBSD and NetBSD, use long.

llvm-svn: 182215

AArch64 ELF uses .rela relocations so there's no need to actually make
use of the bits we're setting in the destination  However, we should
make sure all bits are cleared properly since multiple runs of
resolveRelocations are possible and these could combine to produce
invalid results if stale versions remain in the code.

llvm-svn: 182214

lli's remote MCJIT code calls setExecutable just prior to running
code. In line with Darwin behaviour this seems to be the place to
invalidate any caches needed so that relocations can take effect
properly.

llvm-svn: 182213

llvm-svn: 182212

llvm-svn: 182211

On 32-bit hosts %p can print garbage when given a uint64_t, we should
use %llx instead. This only affects the output of the debugging text
produced by lli.

llvm-svn: 182209

llvm-svn: 182207

Summary: + improved handling of default style and predefined styles.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits

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

llvm-svn: 182205

llvm-svn: 182204

imply -fno-math-errno if the user passed -fno-fast-math OR -ffast-math,
regardless of in which order and regardless of the tool chain default.

I've fixed this to follow the logic:

1) If the last dominating flag is -fno-math-errno, -ffast-math, or
   -Ofast, then do not use math-errno.
2) If the last dominating flag is an explicit -fmath-errno, do use
   math-errno.
3) Otherwise, use the toolchain default.

This, for example, allows the flag sequence
'-ffast-math ... -fno-fast-math' with no mention of '-fmath-errno' or
'-fno-math-errno' to preserve the toolchain default. Most notably, this
should prevent users trying to disable fast-math optimizations on Darwin
and BSD platforms from simultaneously enabling (pointless) -fmath-errno.

I've enhanced the tests (after more reorganization) to cover this and
other weird permutations of flags and targets.

llvm-svn: 182203

setting. Consolidate the collection of tests that enable -fmath-errno
and share a single CHECK line for simplicity.

llvm-svn: 182202

llvm-svn: 182201

This is useful if something that looks like (x & (1 << y)) ? 64 : 32 is
the divisor in a modulo operation.

llvm-svn: 182200

We might encouter single edge PHIs - handle them with an identity select.

Fixes PR15990.

llvm-svn: 182199

llvm-svn: 182198

Patch by Yacine Belkadi.

llvm-svn: 182197

Should help the ppc32 buildbot.

llvm-svn: 182194

We don't need to reject all inline asm as using the counter register (most does
not). Only those that explicitly clobber the counter register need to prevent
the transformation.

llvm-svn: 182191

llvm-svn: 182190

llvm-svn: 182189

llvm-svn: 182188

Constructs like PseudoObjectExpr, where an expression can appear more than
once in the AST, use OpaqueValueExprs to guard against inadvertent
re-processing of the shared expression during AST traversal. The most
common form of this is to share expressions between the syntactic
"as-written" form of, say, an Objective-C property access 'obj.prop', and
the underlying "semantic" form '[obj prop]'.

However, some constructs can produce OpaqueValueExprs that don't appear in
the syntactic form at all; in these cases the ParentMap wasn't ever traversing
the children of these expressions. This patch fixes that by checking to see
if an OpaqueValueExpr's child has ever been traversed before. There's also a
bit of reset logic when visiting a PseudoObjectExpr to handle the case of
updating the ParentMap, which some external clients depend on.

This still isn't exactly the right fix because we probably want the parent
of the OpaqueValueExpr itself to be its location in the syntactic form if
it's syntactic and the PseudoObjectExpr or BinaryConditionalOperator itself
if it's semantic. Whe I originally wrote the code to do this, I didn't realize
that OpaqueValueExprs themselves are shared in the AST, not just their source
expressions. This patch doesn't change the existing behavior so as not to
break anything inadvertently relying on it; we'll come back to this later.

llvm-svn: 182187

Originally implemented by Ted, extended by me.

llvm-svn: 182186

Ted and I spent a long time discussing this today and found out that neither
the existing code nor the new code was doing what either of us thought it
was, which is never good. The good news is we found a much simpler way to
fix the motivating test case (an ObjCSubscriptExpr).

This reverts r182083, but pieces of it will come back in subsequent commits.

llvm-svn: 182185

The peephole tries to reorder MOV32r0 instructions such that they are
before the instruction that modifies EFLAGS.

The problem is that the peephole does not consider the case where the
instruction that modifies EFLAGS also depends on the previous state of
EFLAGS.

Instead, walk backwards until we find an instruction that has a def for
EFLAGS but does not have a use.
If we find such an instruction, insert the MOV32r0 before it.
If it cannot find such an instruction, skip the optimization.

llvm-svn: 182184

the Objective-C object checker and the pointer
checker) were not always installed into expressions.

<rdar://problem/13882566>

llvm-svn: 182183

Thanks to John McCall for pointing this out.

llvm-svn: 182182

The same comment is already made in the header

llvm-svn: 182181

llvm-svn: 182180

Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be.

This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this.

llvm-svn: 182179

llvm-svn: 182178

llvm-svn: 182177

properties declared in a protocol.

rdar://problem/13798000

llvm-svn: 182176

This patch matches GCC behavior: the code used to only allow unaligned
load/store on ARM for v6+ Darwin, it will now allow unaligned load/store
for v6+ Darwin as well as for v7+ on Linux and NaCl.

The distinction is made because v6 doesn't guarantee support (but LLVM
assumes that Apple controls hardware+kernel and therefore have
conformant v6 CPUs), whereas v7 does provide this guarantee (and
Linux/NaCl behave sanely).

The patch keeps the -arm-strict-align command line option, and adds
-arm-no-strict-align. They behave similarly to GCC's -mstrict-align and
-mnostrict-align.

I originally encountered this discrepancy in FastIsel tests which expect
unaligned load/store generation. Overall this should slightly improve
performance in most cases because of reduced I$ pressure.

llvm-svn: 182175

Fix the fact that an empty NSString (e.g. one obtained from @"" would show no summary)

llvm-svn: 182173