| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 175212
|
| |
|
|
|
|
| |
"target modules add" should resolve bundle executables, as should anything else that tries to create a module from a bundle path.
llvm-svn: 175210
|
| |
|
|
| |
llvm-svn: 175209
|
| |
|
|
|
|
|
| |
This also adds a simple relocation change for dynamic executables to
x86-64 ELF.
llvm-svn: 175208
|
| |
|
|
|
|
|
|
|
| |
The purpose of this change is to simplify creating non-atom sections.
Previously _contentType, _sectionKind and _order were used for multiple
purposes and collided in places. This moves all of the Atom specific logic down
into AtomSection and makes Section just have raw Elf_Shdr flags.
llvm-svn: 175207
|
| |
|
|
|
|
| |
directly instead of casting a pointer to an integer
llvm-svn: 175206
|
| |
|
|
|
|
|
|
| |
This patch doesn't introduce any functionality changes.
It adds some new fields to the Hexagon instruction classes and
changes their layout to support instruction encoding.
llvm-svn: 175205
|
| |
|
|
| |
llvm-svn: 175204
|
| |
|
|
| |
llvm-svn: 175203
|
| |
|
|
| |
llvm-svn: 175202
|
| |
|
|
| |
llvm-svn: 175201
|