FunctionArrayLvalueConversion but without the function/array decay. Generally
this is only appropriate for use sites that know the type of the expression
and thus that it can't be subject to the decays.
Also make sure we do lvalue-to-rvalue on the bases of ivar references.
llvm-svn: 121035
My previous attempt at solving the compile-time problem with many
redeclarations of the same entity cached both linkage and visibility,
while this patch only tackles linkage. There are several reasons for
this difference:
- Linkage is a language concept, and is evaluated many times during
semantic analysis and codegen, while visibility is only a
code-generation concept that is evaluated only once per (unique)
declaration. Hence, we *must* optimize linkage calculations but
don't need to optimize visibility computation.
- Once we know the linkage of a declaration, subsequent
redeclarations can't change that linkage. Hence, cache
invalidation is far simpler than for visibility, where a later
redeclaration can completely change the visibility.
- We have 3 spare bits in Decl to store the linkage cache, so the
cache doesn't increase the size of declarations. With the
visibility+linkage cache, NamedDecl got larger.
llvm-svn: 121023
o test_many_expr_commands()
o test_expr_commands_can_handle_quotes()
Mark test_expr_commands_can_handle_quotes()
as @expectedFailure:
# rdar://problem/8686536
# CommandInterpreter::HandleCommand is stripping \'s from input for WantsRawCommand commands
llvm-svn: 121019
and visibility of declarations, because it was extremely messy and it
increased the size of NamedDecl.
An improved implementation is forthcoming.
llvm-svn: 121012
so that's not a valid thing to do at all. Instead, switch to a ValueDecl
argument, the template isn't really necessary here.
When handling the types explicitly in the code, it becomes awkward to cerate
the CXXBaseOrMemberInitializer object in so many places. Re-flow the code to
calculate the Init expression first, and then create the initializer. If this
is too gross, we can factor the init expression logic into helper functions,
but it's not past my threshold yet.
llvm-svn: 120997
optimization.
Consider:
static void foo() {
A = alloca
...
}
static void bar() {
B = alloca
...
call foo();
}
void main() {
bar()
}
The inliner proceeds bottom up, but lets pretend it decides not to inline foo
into bar. When it gets to main, it inlines bar into main(), and says "hey, I
just inlined an alloca "B" into main, lets remember that. Then it keeps going
and finds that it now contains a call to foo. It decides to inline foo into
main, and says "hey, foo has an alloca A, and I have an alloca B from another
inlined call site, lets reuse it". The problem with this of course, is that
the lifetime of A and B are nested, not disjoint.
Unfortunately I can't create a reasonable testcase for this: the one in the
PR is both huge and extremely sensitive, because you minor tweaks end up
causing foo to get inlined into bar too early. We already have tests for the
basic alloca merging optimization and this does not break them.
llvm-svn: 120995
the LHS, or else the pointer might be invalid. This is kindof dumb, but
go ahead and make sure we're doing that for l-value scalar assignment,
which fixes a miscompile of obj-c++.dg/block-seq.mm.
Leave a FIXME for how to solve this problem for agg __blocks.
llvm-svn: 120992
build one when either of the operands calls itself type-dependent;
previously we were building when one of the operand types was dependent,
which is not always the same thing and which can lead to unfortunate
inconsistencies later. Fixes PR8739.
llvm-svn: 120990
Jason W Kim