| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
peephole I added in r250916.
rdar://23559789
llvm-svn: 253255
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14266
llvm-svn: 252220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions.
This commit fixes a bug in CGOpenMPRuntime.cpp and CGObjC.cpp where
some of the function attributes are not attached to newly created
functions.
rdar://problem/20828324
Differential Revision: http://reviews.llvm.org/D13928
llvm-svn: 251476
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, handle under-aligned object references (by explicitly
ignoring them, because this just isn't representable in the format;
yes, this means that GC silently ignores such references), descend
into anonymous structs and unions, stop classifying fields of
pointer-to-strong/weak type as strong/weak in ARC mode, and emit
skips to cover the entirety of block layouts in GC mode. As a
cleanup, extract this code into a helper class, avoid a number of
unnecessary copies and layout queries, generate skips implicitly
instead of explicitly tracking them, and clarify the bitmap-creation
logic.
llvm-svn: 250919
|
|
|
|
|
|
|
| |
a value loaded from a __weak variable into a call to
objc_copyWeak or objc_moveWeak.
llvm-svn: 250916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The store being checked for in arc-cxx11-init-list.mm is a store to an
unescaped alloca. After an uncoming change to ScalarEvolution, LLVM is
able to elide the store, so adjust the test accordingly.
Reviewers: compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13183
llvm-svn: 248632
|
|
|
|
|
|
|
|
|
| |
it escaped notice because it's only used for heterogeneous
initialization.
rdar://21397946
llvm-svn: 247597
|
|
|
|
|
|
|
|
| |
if they have the same alignment and one was 'this'.
Fixes PR24780.
llvm-svn: 247482
|
|
|
|
|
|
|
| |
I accidentally introduced a bug locally, and noticed that none of the tests
caught it. No longer!
llvm-svn: 247477
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace:
'try { throw 0; } catch (...)'
with
'try { throw 0; } catch (int e)'
in two test cases.
Differential Revision: http://reviews.llvm.org/D12743
llvm-svn: 247437
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When uses of personality functions were moved from LandingPadInst to
Function, we forgot to update SimplifyPersonality(). This patch corrects
that.
Note: SimplifyPersonality() is an optimization which replaces
personality functions with the default C++ personality when possible.
Without this update, some ObjC++ projects fail to link against C++
libraries (seeing as the exception ABI had effectively changed).
rdar://problem/22155434
llvm-svn: 247421
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a contextually-typed expression that semantic analysis will
probably need to invasively rewrite, don't include the
RHS OVE as a separate semantic expression, and check the
operation with the original RHS expression.
There are two contextually-typed expressions that can survive
to here: overloaded function references, which are at least
safe to double-emit, and C++11 initializer list expressions,
which are not at all safe to double-emit and which often
don't update the original syntactic InitListExpr with
implicit conversions to member types, etc.
This means that the original RHS may appear, undecorated by
an OVE, in the semantic expressions. Fortunately, it will
only ever be used in a single place there, and I don't
believe there are clients that rely on being able to pick
out the original RHS from the semantic expressions.
But this could be problematic if there are clients that do
visit the entire tree and rely on not seeing the same
expression multiple times, once in the syntactic and once
in the semantic expressions. This is a very fiddly part
of the compiler.
rdar://21801088
llvm-svn: 245771
|
|
|
|
|
|
| |
designated enum.
llvm-svn: 243355
|
|
|
|
|
|
|
| |
For designated indices use the max array size type bitwidth, not the bitwidth of the index value itself.
rdar://21942503
llvm-svn: 243343
|
|
|
|
|
|
|
|
|
|
| |
The __kindof type qualifier can be applied to Objective-C object
(pointer) types to indicate id-like behavior, which includes implicit
"downcasting" of __kindof types to subclasses and id-like message-send
behavior. __kindof types provide better type bounds for substitutions
into unspecified generic types, which preserves more type information.
llvm-svn: 241548
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cases
Several tests wouldn't pass when executed on an armv7a_pc_linux triple
due to the non-default arm_aapcs calling convention produced on the
function definitions in the IR output. Account for this with the
application of a little regex.
Patch by Ying Yi.
llvm-svn: 240971
|
|
|
|
| |
llvm-svn: 239941
|
|
|
|
| |
llvm-svn: 239848
|
|
|
|
|
|
| |
rdar://problem/20571359
llvm-svn: 239781
|
|
|
|
|
|
|
| |
details in http://reviews.llvm.org/D9483
goes with llvm checkin r237150
llvm-svn: 237151
|
|
|
|
|
|
|
|
|
|
| |
LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week. This
commit was generated using the rename-md-di-nodes.sh upgrade script
attached to PR23080, followed by running clang-format-diff.py on the
`lib/` portion of the patch.
llvm-svn: 236121
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
(migration for recent LLVM change to textual IR for calls)
llvm-svn: 235147
|
|
|
|
|
|
|
| |
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: 232237
|
|
|
|
| |
llvm-svn: 232187
|
|
|
|
|
|
|
| |
Update testcases for LLVM change in r231082 to use the new debug info
hierarchy.
llvm-svn: 231083
|
|
|
|
| |
llvm-svn: 230795
|
|
|
|
| |
llvm-svn: 230783
|
|
|
|
|
|
| |
rdar://problem/19839612
llvm-svn: 229522
|
|
|
|
|
|
| |
migration
llvm-svn: 229273
|
|
|
|
|
|
| |
change updates
llvm-svn: 229197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
distinction between the different use-cases. With the previous default
behavior we would occasionally emit empty debug locations in situations
where they actually were strictly required (= on invoke insns).
We now have a choice between defaulting to an empty location or an
artificial location.
Specifically, this fixes a bug caused by a missing debug location when
emitting C++ EH cleanup blocks from within an artificial function, such as
an ObjC destroy helper function.
rdar://problem/19670595
llvm-svn: 228003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.
The advantages of the change are that
* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.
* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.
llvm-svn: 226751
|
|
|
|
|
|
| |
Update testcases to match LLVM change in r226048.
llvm-svn: 226049
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and ObjC methods
Without setting the CurEHLocation these cleanups would be attributed to
whatever the last active debug line location was (the 'fn' call in the
included test cases). By setting CurEHLocation correctly the line
information is improved/corrected.
This quality bug turned into a crasher with r225000 when, instead of
allowing the last location to persist, it would be zero'd out. This
could lead to a function call (such as the dtor) being made without a
debug location - if that call was subsequently inlined (and the caller
and callee had debug info, just not the call instruction) the inliner
would violate important constraints about the debug location chains by
not updating the inlined instructions to chain up to the callee
locations.
So, by fixing this bug, I am addressing the assertion failures
introduced by r225000 and should be able to recommit that patch with
impunity...
llvm-svn: 225955
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was previously piggybacking on whatever happened to be the last
location set on CGDebugInfo/DIBuilder, which was wrong (it was often the
current location, such as the 'fn()' call site, not the end of the
block). With my improvements to set/unset the location in a scoped
manner (r225000) this went from a bad quality situation, to a crash.
Fixing this goes part-way to unblocking the recommit of r225000.
It's likely that any call to CodeGenFunction::StartFunction without the
CurEHLocation set represents a similar bug or risk of a bug. Perhaps
there are some callers that know they won't generate EH cleanups, but
I'm not sure.
I considered a generic catch-fix in StartFunction (just fallback to the
GlobalDecl's location) but that seemed like it'd mask bugs where the EH
location shouldn't be the same as the decl's location (& indeed by not
using that stop-gap I found this bug). We'll see how long I can hold out
on the generic catch-all. I might eventually be able to add an assertion
in.
llvm-svn: 225845
|
|
|
|
|
|
|
|
|
| |
is for each machine. Fix up darwin tests that were testing for
aapcs on armv7-ios when the actual ABI is apcs.
Should be no user visible change without -cc1.
llvm-svn: 223429
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
We didn't consider types like ObjCSel as a substitution candidate.
This fixes PR21688.
llvm-svn: 222941
|
|
|
|
|
|
| |
canonicalization in r222748. No interesting functionality changed here.
llvm-svn: 222749
|
|
|
|
| |
llvm-svn: 221843
|
|
|
|
|
|
|
| |
for class that contains trivially-constructible struct ivar.
rdar://18950072
llvm-svn: 221823
|
|
|
|
|
|
| |
Simply marking the symbol private conveys the desire to hide them to LLVM.
llvm-svn: 221451
|
|
|
|
| |
llvm-svn: 220812
|
|
|
|
|
|
|
| |
The temporary initialized is referenced as %0, not as the auto-release pool.
Fixes R+A tests.
llvm-svn: 220593
|