llvm-svn: 175264

When prelink is installed in the system, prelink-ed
libraries map between 0x003000000000 and 0x004000000000 thus occupying the shadow Gap,
so we need so split the address space even further, like this:
|| [0x10007fff8000, 0x7fffffffffff] || HighMem    ||
|| [0x02008fff7000, 0x10007fff7fff] || HighShadow ||
|| [0x004000000000, 0x02008fff6fff] || ShadowGap3 ||
|| [0x003000000000, 0x003fffffffff] || MidMem     ||
|| [0x00087fff8000, 0x002fffffffff] || ShadowGap2 ||
|| [0x00067fff8000, 0x00087fff7fff] || MidShadow  ||
|| [0x00008fff7000, 0x00067fff7fff] || ShadowGap  ||
|| [0x00007fff8000, 0x00008fff6fff] || LowShadow  ||
|| [0x000000000000, 0x00007fff7fff] || LowMem     ||

Do it only if necessary.

Also added a bit of profiling code to make sure that the
mapping code is efficient.

Added a lit test to simulate prelink-ed libraries.
Unfortunately, this test does not work with binutils-gold linker.
If gold is the default linker the test silently passes.

Also replaced
__has_feature(address_sanitizer)
with
__has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
in two places.

Patch partially by Jakub Jelinek.

llvm-svn: 175263

This is almost always more readable.

Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    ? aaaaaaaaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaaaaaaaaaaaaaaaa;

After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    ? aaaaaaaaaaaaaaaaaaaaaaaaaaa
    : aaaaaaaaaaaaaaaaaaaaaaaaaaa;

llvm-svn: 175262

This implements the review suggestion to simplify the AArch64 backend. If we
later discover that we *really* need the extra complexity of the
ConstantIslands pass for performance reasons it can be resurrected.

llvm-svn: 175258

In the near future litpools will be in a different section, which means that
any access to them is at least two instructions. This makes the case for a
movz/movk pair (if total offset <= 32-bits) even more compelling.

llvm-svn: 175257

llvm-svn: 175255

llvm-svn: 175253

llvm-svn: 175252

For some basic blocks, it is possible to generate many candidate pairs for
relatively few pairable instructions. When many (tens of thousands) of these pairs
are generated for a single instruction group, the time taken to generate and
rank the different vectorization plans can become quite large. As a result, we now
cap the number of candidate pairs within each instruction group. This is done by
closing out the group once the threshold is reached (set now at 3000 pairs).

Although this will limit the overall compile-time impact, this may not be the best
way to achieve this result. It might be better, for example, to prune excessive
candidate pairs after the fact the prevent the generation of short, but highly-connected
groups. We can experiment with this in the future.

This change reduces the overall compile-time slowdown of the csa.ll test case in
PR15222 to ~5x. If 5x is still considered too large, a lower limit can be
used as the default.

This represents a functionality change, but only for very large inputs
(thus, there is no regression test).

llvm-svn: 175251

This reverts commit 82c101153fe7b35bce48781fab038e1b8f31a7bd.

llvm-svn: 175250

This reverts commit 58f20a3cbfca7384fe5e25e095f18572736a4792.

llvm-svn: 175249

This reverts commit 997c6516ca161073a1d516ebca7c0ca7722f64e2.

llvm-svn: 175248

If testing on Linux+clang proves it needs RTTI, wa can remove the
conditionals.

llvm-svn: 175242

A little cleanup.  {Disable/Enable}Breakpoint actually disables/enables BreakpointSites not breakpoints, it is confusing
to have it not named appropriately.  Also in StopInfoMachException, we aren't testing for software or not software, just
whether the thing is a breakpoint we set.  So don't use "software"...

llvm-svn: 175241

This just adds a very simple check that if a DerivedToBase CastExpr is
operating on a value with known C++ object type, and that type is not the
base type specified in the AST, then the cast is invalid and we should
return UnknownVal.

In the future, perhaps we can have a checker that specifies that this is
illegal, but we still shouldn't assert even if the user turns that checker
off.

PR14872

llvm-svn: 175239

llvm-svn: 175238

not matter but makes it more gcc compatible which avoids possible subtle
problems. Also, turned back on a disabled check in helloworld.ll. 

llvm-svn: 175237

llvm-svn: 175236

llvm-svn: 175235

...after a host of optimizations related to the use of LazyCompoundVals
(our implementation of aggregate binds).

Originally applied in r173951.
Reverted in r174069 because it was causing hangs.
Re-applied in r174212.
Reverted in r174265 because it was /still/ causing hangs.

If this needs to be reverted again it will be punted to far in the future.

llvm-svn: 175234

This means we don't have to recompute them all later for every
removeDeadSymbols check.

llvm-svn: 175233

Previously, we were scanning the current store. Now, we properly scan the
store that the LazyCompoundVal came from, which may have very different
live symbols.

llvm-svn: 175232

This is optimization only; no behavioral change.

llvm-svn: 175231

Previously, whenever we had a LazyCompoundVal, we crawled through the
entire store snapshot looking for bindings within the LCV's region. Now, we
just ask for the subregion bindings of the lazy region and only visit those.

This is an optimization (so no test case), but it may allow us to clean up
more dead bindings than we were previously.

llvm-svn: 175230

Daniel Malea caught an issue where calling dotest.py with an invalid directory would cause the progressbar init code to raise an exception
This commit fixes it

llvm-svn: 175229

This is going to be used in the next commit.
While I'm here, tighten up assumptions about symbolic offset
BindingKeys, and make offset calculation explicitly handle all
MemRegion kinds.

No functionality change.

llvm-svn: 175228

The SEL data formatter was working hard to ensure that pointers-to-selectors could be formatted by the same block of code. In that effort, we were taking the address-of a SEL.
This operation fails when the SEL lives in a register, and was causing problems.
The formatter has been fixed to work correctly without assuming &selector will be a valid object.

llvm-svn: 175227

Unfortunately, I wasn't able to create a test case that demonstrates the
problem I was trying to fix with this patch.

llvm-svn: 175226

defined and used registers. Also add a few helper functions to simplify the
code. 

llvm-svn: 175224

- stop ignoring the error-codes in the 'error' variable
- removed out-of-bounds accesses with read-only array fields such as:

  self.assertTrue(data2.uint8[6] == 0, 'binary 0 terminator')

Since SBData wraps a (6-character) python string literal, trying to read the
null-terminator raises an exception. Instead, I replaced the out-of-bounds
read with a length-check.

Other out-of-bounds reads (via accessor function like SBData.GetUnsignedInt8)
don't throw and are OK. I just added asserts that errors are set for these
negative cases.

llvm-svn: 175223

llvm-svn: 175222

assembler should also accept a two arg form, as the docuemntation specifies that
the first (destination) register is optional.

This patch uses TwoOperandAliasConstraint to add the two argument form.

It also fixes an 80-column formatting problem in:
  test/MC/ARM/neon-bitwise-encoding

<rdar://problem/12909419> Clang rejects ARM NEON assembly instructions

llvm-svn: 175221

llvm-svn: 175220

1. Define and use function terminateSearch.
2. Use MachineBasicBlock::iterator instead of MachineBasicBlock::instr_iterator.
3. Delete the line which checks whether an instruction is a pseudo. 

llvm-svn: 175219

Patch by Tyler Nowicki.

llvm-svn: 175218

// rdar://13192366

llvm-svn: 175217

All instances of std::multimap have now been replaced by
DenseMap<K, std::vector<V> >, and this yields a speedup of 5% on the
csa.ll test case from PR15222.

No functionality change intended.

llvm-svn: 175216

This is another commit on the road to removing std::multimap from
BBVectorize. This gives an ~1% speedup on the csa.ll test case
in PR15222.

No functionality change intended.

llvm-svn: 175215

declarations to synthesize their ivars in similar
determinstic order so they are laid out in
a determinstic order. // rdar://13192366

llvm-svn: 175214

llvm-svn: 175213