Commit Graph

20 Commits

Author SHA1 Message Date
Eli Friedman 62f3ef2b53 [CGCall] Annotate references with "align" attribute.
If we're going to assume references are dereferenceable, we should also
assume they're aligned: otherwise, we can't actually dereference them.

See also D80072.

Differential Revision: https://reviews.llvm.org/D80166
2020-05-19 20:21:30 -07:00
Sean Fertile d900dd0c23 Revert "[CodeGenCXX] Treat 'this' as noalias in constructors"
This reverts commit https://reviews.llvm.org/rL344150 which causes
MachineOutliner related failures on the ppc64le multistage buildbot.

llvm-svn: 344526
2018-10-15 15:43:00 +00:00
Anton Bikineev cc7e74753a [CodeGenCXX] Treat 'this' as noalias in constructors
This is currently a clang extension and a resolution
of the defect report in the C++ Standard.

Differential Revision: https://reviews.llvm.org/D46441

llvm-svn: 344150
2018-10-10 16:14:51 +00:00
Akira Hatanaka 797afe3a4e [CodeGen] Ignore OpaqueValueExprs that are unique references to their
source expressions when iterating over a PseudoObjectExpr's semantic
subexpression list.

Previously the loop in emitPseudoObjectExpr would emit the IR for each
OpaqueValueExpr that was in a PseudoObjectExpr's semantic-form
expression list and use the result when the OpaqueValueExpr later
appeared in other expressions. This caused an assertion failure when
AggExprEmitter tried to copy the result of an OpaqueValueExpr and the
copied type didn't have trivial copy/move constructors or assignment
operators.

This patch adds flag IsUnique to OpaqueValueExpr which indicates it is a
unique reference to its source expression (it is not used in multiple
places). The loop in emitPseudoObjectExpr ignores OpaqueValueExprs that
are unique and CodeGen visitors simply traverse the source expressions
of such OpaqueValueExprs.

rdar://problem/34363596

Differential Revision: https://reviews.llvm.org/D39562

llvm-svn: 327939
2018-03-20 01:47:58 +00:00
Peter Collingbourne 0900fe0f1b CodeGen: Update for debug info API change.
Differential Revision: http://reviews.llvm.org/D14266

llvm-svn: 252220
2015-11-05 22:04:14 +00:00
Douglas Katzman 3459ce2e5e Stop messing with the 'g' group of options in CompilerInvocation.
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
2015-10-08 04:24:12 +00:00
John McCall ee04aebbdb When building a pseudo-object assignment, and the RHS is
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
2015-08-22 00:35:27 +00:00
David Blaikie 8e6c36eb80 DebugInfo: Don't leak location information from one function into the prologue of the next function.
CodeGenFunction objects aren't really designed to be reused for more
than one function, and doing so can leak debug info location information
from one function into the prologue of the next.

Add an assertion in to catch reuses of CodeGenFunction, which
surprisingly only caught the ObjC atomic getter/setter cases. Fix those
and add a test to demonstrate the issue.

The test is a bit slim, because we're just testing for the absence of a
debug location on the prologue instructions, which by itself probably
wouldn't be the end of the world - but the particular debug location
that was ending up there was for the previous function's last
instruction. This produced debug info for another function within this
function, which is something I'm trying to remove all cases of as its a
substantial source of bugs, especially around inlining (see r219215).

llvm-svn: 219690
2014-10-14 16:43:46 +00:00
Hal Finkel a2347baaec Mark C++ reference parameters as dereferenceable
Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.

Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.

llvm-svn: 213386
2014-07-18 15:52:10 +00:00
Nick Lewycky 9b46eb8112 Add 'nonnull' parameter or return attribute when producing an llvm pointer type in a function type where the C++ type is a reference. Update the tests.
llvm-svn: 209723
2014-05-28 09:56:42 +00:00
Stephen Lin 4362261b00 CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.
llvm-svn: 188447
2013-08-15 06:47:53 +00:00
Eli Friedman 00fa429b5d Don't try to save the assigned value in a Objective-C property assignment
if the type of the value is a non-trivial class type.  Fixes PR14318.

(There's a minor ObjC++ language change here: given that we can't save the
value, the type of the assignment expression is void in such cases.)

llvm-svn: 167884
2012-11-13 23:16:33 +00:00
John McCall 9b0a7cea0f Make -fobjc-nonfragile-abi the -cc1 default, since it's the
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
2011-10-02 01:16:38 +00:00
Chris Lattner a5f58b05e8 clang side to match the LLVM IR type system rewrite patch.
llvm-svn: 134831
2011-07-09 17:41:47 +00:00
Fariborz Jahanian e89d03f619 property reference expression used on lhs of assignment
follows objective's semantics and is not overload'able
with an assignment operator. Fixes a crash and a missing
diagnostics. Radar 8379892.

llvm-svn: 113555
2010-09-09 23:01:10 +00:00
Fariborz Jahanian 61a312413c Fix IRGen when property-dot syntax used to access
a c++ class object 'ivar'. Fixes radar 8366604.

llvm-svn: 112729
2010-09-01 19:36:41 +00:00
Fariborz Jahanian e1b45a5e6b Fix API gen for objc_msgSend property of aggregate types
in Objective-c++ mode. Fixes radar 7986354.

llvm-svn: 103887
2010-05-15 23:05:52 +00:00
Fariborz Jahanian 43a40f9399 Objective-C++ Code gen. Handle code gen. for property
reference dot-syntax notation in a varierty of cases.
Fixes radar 7964490.

llvm-svn: 103440
2010-05-10 22:57:35 +00:00
Fariborz Jahanian fdf474b05e Fixes a Code gen crash trying to use a dot-syntax for
a property of a c++ class object (radar 7957369).

llvm-svn: 103279
2010-05-07 18:56:13 +00:00
Fariborz Jahanian b8993384f3 Code Gen support for Getter/Setter synthesis of
C++ object properties. (still radar 7468090).

llvm-svn: 103182
2010-05-06 15:45:36 +00:00