| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 249206
|
| |
|
|
|
|
|
|
|
|
|
| |
I randomly came across this difference between AArch64 and other targets:
on the latter, we don't emit nil checks for known non-nil class method
calls thanks to r247350, but we still do for AArch64 stret calls.
They use different code paths, because those are special, as they go
through the regular msgSend, not the msgSend*_stret variants.
llvm-svn: 249205
|
| |
|
|
| |
llvm-svn: 249204
|
| |
|
|
|
|
|
|
| |
test run
was terminated (e.g., due timeout).
llvm-svn: 249203
|
| |
|
|
|
|
|
|
| |
LLVM_BUILD_EXTERNAL_COMPILER_RT can depend on llvm-config.
This patch is a required stepping stone to fix PR14109.
llvm-svn: 249202
|
| |
|
|
| |
llvm-svn: 249201
|
| |
|
|
| |
llvm-svn: 249200
|
| |
|
|
|
|
| |
The darwin and macho_embedded libraries get installed to different locations, so we need to feed through an INSTALL_PATH.
llvm-svn: 249199
|
| |
|
|
|
|
| |
Fix style while I'm here.
llvm-svn: 249198
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that the vptr store in the most-derived constructor is not behind
an invariant group barrier. Previously, the base-most vptr store would
be the one behind no barrier, and that could result in the creator of
the object thinking it had the base-most vtable.
This bug caused clang call pure virtual functions when called from
constructor body.
http://reviews.llvm.org/D13373
llvm-svn: 249197
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The most important part required to make clang
devirtualization works ( ͡°͜ʖ ͡°).
The code is able to find non local dependencies, but unfortunatelly
because the caller can only handle local dependencies, I had to add
some restrictions to look for dependencies only in the same BB.
http://reviews.llvm.org/D12992
llvm-svn: 249196
|
| |
|
|
| |
llvm-svn: 249195
|
| |
|
|
| |
llvm-svn: 249194
|
| |
|
|
| |
llvm-svn: 249193
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Hi Marshall,
Could you please test this patch and see if you run into the same linker errors we talked about?
I can't reproduce on linux or OS X.
Hopefully you can't find any problems and we can fix the C++03 bot.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13337
llvm-svn: 249192
|
| |
|
|
| |
llvm-svn: 249191
|
| |
|
|
| |
llvm-svn: 249190
|
| |
|
|
| |
llvm-svn: 249189
|
| |
|
|
| |
llvm-svn: 249188
|
| |
|
|
| |
llvm-svn: 249187
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13397
llvm-svn: 249186
|
| |
|
|
|
|
|
|
| |
to other types beyond the well-known ones
This is meant to support languages that can do some sort of bridging from<-->to these ObjC types via types that statically vend themselves as Cocoa types, but dynamically have an implementation that does not match any of our well-known types, but where an introspecting formatter can be vended by the bridged language
llvm-svn: 249185
|
| |
|
|
| |
llvm-svn: 249184
|
| |
|
|
|
|
|
| |
Call the correct overload so a string literal does not get converted to a bool.
Also fix the test case to match the names given.
llvm-svn: 249183
|
| |
|
|
|
|
|
| |
This fixes:
https://llvm.org/bugs/show_bug.cgi?id=25019
llvm-svn: 249182
|
| |
|
|
| |
llvm-svn: 249181
|
| |
|
|
| |
llvm-svn: 249179
|
| |
|
|
| |
llvm-svn: 249178
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We will shortly re-use this for select-like br-phi pairs.
Reviewers: atrick, joker-eph, joker.eph
Subscribers: sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D13377
llvm-svn: 249177
|
| |
|
|
| |
llvm-svn: 249176
|
| |
|
|
|
|
|
| |
This adds entries in the dynamic table for .init_array, .fini_array and
.preinit_array.
llvm-svn: 249175
|
| |
|
|
| |
llvm-svn: 249174
|
| |
|
|
|
|
| |
description of what's going on.
llvm-svn: 249173
|
| |
|
|
| |
llvm-svn: 249172
|
| |
|
|
| |
llvm-svn: 249171
|
| |
|
|
|
|
|
| |
Make sure we aren't accidentally not setting
these in the instruction definitions.
llvm-svn: 249170
|
| |
|
|
|
|
|
| |
The alternative would be to add a bit to the target's
InstrFlags but that seems like a waste of a bit.
llvm-svn: 249169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change teaches SCEV that to prove `A u< B` it is sufficient to
prove each of these facts individually:
- B >= 0
- A s< B
- A >= 0
In practice, SCEV sometimes finds it easier to prove these facts
individually than to prove `A u< B` as one atomic step.
Reviewers: reames, atrick, nlewycky, hfinkel
Subscribers: sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D13042
llvm-svn: 249168
|
| |
|
|
|
|
|
| |
Also made it not store nullptrs in its TypeSystemMap, so it will retry to make
the AST context if it errored out last time.
llvm-svn: 249167
|
| |
|
|
| |
llvm-svn: 249166
|
| |
|
|
| |
llvm-svn: 249165
|
| |
|
|
|
|
|
|
|
| |
We previously stopped producing Thumb2 relaxations when they weren't supported,
but only diagnosed the case where an actual relocation was produced. We should
also tell people if local symbols aren't going to work rather than silently
overflowing.
llvm-svn: 249164
|
| |
|
|
|
|
|
| |
Since we're using tLDRpci to access it, the constant pool's address must be 0
(mod 4).
llvm-svn: 249163
|
| |
|
|
|
|
|
| |
As Rafael pointed out, we don't need quite so many flags on the llvm-readobj
RUN line here.
llvm-svn: 249162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is common to have a default soft process limit, at least on some families of
Linux distributions, of 1024. This is normally more than enough, but if you
have many cores, and you're running tests that create many threads, this can
become a problem. My POWER7 development machine has 48 cores, and when running
the lld regression tests, which often want to create up to 48 threads, I run
into problems. lit, by default, will want to run 48 tests in parallel, and
48*48 < 1024, and so many tests fail like this:
terminate called after throwing an instance of 'std::system_error'
what(): Resource temporarily unavailable
or lit fails like this when launching a test:
OSError: [Errno 11] Resource temporarily unavailable
lit can easily detect this situation and attempt to repair it before launching
tests (by raising the soft process limit to something that will allow ncpus^2
threads to be created), and should do so to prevent spurious test failures.
This is the follow-up to this thread:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/090942.html
llvm-svn: 249161
|
| |
|
|
| |
llvm-svn: 249160
|
| |
|
|
| |
llvm-svn: 249159
|
| |
|
|
|
|
| |
This should resolve an issue reported by mclow.
llvm-svn: 249158
|
| |
|
|
|
|
| |
A forward declaration inside a module header does not belong to the module.
llvm-svn: 249157
|
| |
|
|
| |
llvm-svn: 249156
|