| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Also sink function calls without used results (PR41259)"
Third time's the charm.
This was reverted in r363220 due to being suspected of an internal benchmark
regression and a test failure, none of which turned out to be caused by this.
llvm-svn: 363529
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SinkCommonCodeFromPredecessors ...'
We have observed some failures with internal builds with this revision.
- Performance regressions:
- llvm's SingleSource/Misc evalloop shows performance regressions (although these may be red herrings).
- Benchmarks for Abseil's SwissTable.
- Correctness:
- Failures for particular libicu tests when building the Google AppEngine SDK (for PHP).
hwennborg has already been notified, and is aware of reproducer failures.
llvm-svn: 363220
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also sink function calls without used results (PR41259)"
This was reverted in r360086 as it was supected of causing mysterious test
failures internally. However, it was never concluded that this patch was the
root cause.
> The code was previously checking that candidates for sinking had exactly
> one use or were a store instruction (which can't have uses). This meant
> we could sink call instructions only if they had a use.
>
> That limitation seemed a bit arbitrary, so this patch changes it to
> "instruction has zero or one use" which seems more natural and removes
> the need to special-case stores.
>
> Differential revision: https://reviews.llvm.org/D59936
llvm-svn: 361811
|
| |
|
|
|
|
|
|
|
|
| |
sink function calls without used results (PR41259)"
This reverts r357452 (git commit 21eb771dcb5c11d7500fa6ad551c97a921997f05).
This was causing strange optimization-related test failures on an internal test. Will followup with more details offline.
llvm-svn: 360086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function calls without used results (PR41259)
The original commit caused false positives from AddressSanitizer's
use-after-scope checks, which have now been fixed in r358478.
> The code was previously checking that candidates for sinking had exactly
> one use or were a store instruction (which can't have uses). This meant
> we could sink call instructions only if they had a use.
>
> That limitation seemed a bit arbitrary, so this patch changes it to
> "instruction has zero or one use" which seems more natural and removes
> the need to special-case stores.
>
> Differential revision: https://reviews.llvm.org/D59936
llvm-svn: 358483
|
| |
|
|
|
|
|
|
|
|
| |
function calls without used results (PR41259)'
This revision causes tests to fail under ASAN. Since the cause of the failures
is not clear (could be ASAN, could be a Clang bug, could be a bug in this
revision), the safest course of action seems to be to revert while investigating.
llvm-svn: 357667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
used results (PR41259)
The code was previously checking that candidates for sinking had exactly
one use or were a store instruction (which can't have uses). This meant
we could sink call instructions only if they had a use.
That limitation seemed a bit arbitrary, so this patch changes it to
"instruction has zero or one use" which seems more natural and removes
the need to special-case stores.
Differential revision: https://reviews.llvm.org/D59936
llvm-svn: 357452
|
| |
|
|
| |
llvm-svn: 299877
|
| |
|
|
|
|
|
| |
The change in rL281586 is in llvm component and tests updated here are
in clang component, so I have to commit them consecutively.
llvm-svn: 281587
|
| |
|
|
| |
llvm-svn: 247712
|
| |
|
|
| |
llvm-svn: 239848
|
| |
|
|
|
|
|
|
| |
This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug which was uncovered by
optimizations exposed by the markers.
llvm-svn: 235553
|
| |
|
|
|
|
|
| |
If the revert helps, I'll get a repro this Monday. Else I'll put the change
back in.
llvm-svn: 234700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.
My previous commit (r222993) was not handling debuginfo correctly, but
this could only be seen with some asan tests. Basically, lifetime markers
are just instrumentation for the compiler's usage and should not affect
debug information; however, the cleanup infrastructure was assuming it
contained only destructors, i.e. actual code to be executed, and was
setting the breakpoint for the end of the function to the closing '}', and
not the return statement, in order to show some destructors have been
called when leaving the function. This is wrong when the cleanups are only
lifetime markers, and this is now fixed.
llvm-svn: 234581
|
| |
|
|
| |
llvm-svn: 230795
|
| |
|
|
|
|
| |
Revert r222993 while I investigate some MemorySanitizer failures.
llvm-svn: 222995
|
| |
|
|
|
|
|
|
|
| |
Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.
llvm-svn: 222993
|
| |
|
|
|
|
| |
Revert this patch while I investigate some sanitizer failures off-line.
llvm-svn: 219307
|
| |
|
|
|
|
|
|
|
| |
Boostrapping LLVM+Clang+LLDB without threshold on object size for
lifetime markers insertion has shown there was no significant change
in compile time, so let the stack slot colorizer do its optimization
for all slots.
llvm-svn: 219303
|
| |
|
|
|
|
| |
tests fail.
llvm-svn: 188447
|
| |
|
|
|
|
|
|
|
|
|
|
| |
a normal cleanup when entering a @try or @synchronized to
ensure that we clean that up if an exception is triggered.
Apparently GCC did this, so it's hard to argue that we shouldn't
do at least as much.
rdar://12364847
llvm-svn: 178599
|
| |
|
|
| |
llvm-svn: 164987
|
| |
|
|
|
|
|
| |
Left in a note that we need to turn it back on once the SROA fallout is cleared
up.
llvm-svn: 164733
|
| |
|
|
|
|
|
| |
the new SROA pass. This is a benign change: the order of PHI nodes
changed.
llvm-svn: 164481
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
|
| |
|
|
| |
llvm-svn: 144597
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
llvm-svn: 140957
|
| |
|
|
|
|
|
|
| |
-fobjc-exceptions flag to turn them on.
Update all tests accordingly.
llvm-svn: 126177
|
| |
|
|
| |
llvm-svn: 125705
|
| |
|
|
| |
llvm-svn: 124715
|
| |
|
|
|
|
| |
ret duplication.
llvm-svn: 124476
|
| |
|
|
| |
llvm-svn: 124474
|
| |
|
|
|
|
|
| |
both @catches and a @finally, because the second call to @objc_exception_try_enter
will clobber the exception slot. Fixes rdar://problem/8440970.
llvm-svn: 115575
|
| |
|
|
| |
llvm-svn: 110770
|
| |
|
|
|
|
|
|
|
| |
where we weren't accounting for the possibility that a @finally block might
have internal cleanups and therefore might write to the cleanup destination slot.
Fixes <rdar://problem/8293901>.
llvm-svn: 110760
|
| |
|
|
|
|
|
|
|
|
|
| |
ObjC exceptions:
- don't enter a try for the catch blocks unless there's a finally
- put the setjmp buffer in the locals set for liveness reasons
- dump the sync object into an alloca in the locals set for liveness reasons
Some of this can go away if the backend starts to properly calculate liveness
in the presence of setjmp (which would also be a *much* stabler solution).
llvm-svn: 110188
|
| |
|
|
|
|
|
|
|
| |
the magic of inline assembly. Essentially we use read and write hazards
on the set of local variables to force flushing locals to memory
immediately before any protected calls and to inhibit optimizing locals
across the setjmp->catch edge. Fixes rdar://problem/8160285
llvm-svn: 109960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
self-host. Hopefully these results hold up on different platforms.
I tried to keep the GNU ObjC runtime happy, but it's hard for me to test.
Reimplement how clang generates IR for exceptions. Instead of creating new
invoke destinations which sequentially chain to the previous destination,
push a more semantic representation of *why* we need the cleanup/catch/filter
behavior, then collect that information into a single landing pad upon request.
Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional
control flow) are generated, since it's actually fairly closely tied in with
the former. Remove the need to track which cleanup scope a block is associated
with.
Document a lot of previously poorly-understood (by me, at least) behavior.
The new framework implements the Horrible Hack (tm), which requires every
landing pad to have a catch-all so that inlining will work. Clang no longer
requires the Horrible Hack just to make exceptions flow correctly within
a function, however. The HH is an unfortunate requirement of LLVM's EH IR.
llvm-svn: 107631
|
|
|
chain outwards when inside a nested exception scope.
- A real test for this is going into LLVM test-suite.
llvm-svn: 102204
|
