Chris Lattner [Sun, 10 Jul 2011 06:03:22 +0000 (06:03 +0000)]
implement a nice new optimization: CodeGenTypes::UpdateCompletedType
is called whenever a tag type is completed. We previously used that
as the sign to layout the codegen representation for the tag type,
which worked but meant that we laid out *every* completed type, whether
it was used or not.
Now we just lay out the type if we've already seen it somehow else.
This means that we lay out types we've used but haven't seen a body
for, but we don't lay out tons of stuff that noone cares about.
Chris Lattner [Sun, 10 Jul 2011 05:53:24 +0000 (05:53 +0000)]
enhance EmitLValueForFieldInitialization to do the proper pointer adjustment, allowing
us to revert the other half of r134860. Now things are back to a relatively tidy state.
Chris Lattner [Sun, 10 Jul 2011 05:39:13 +0000 (05:39 +0000)]
keep track of whether being in a RS_StructPointer state
caused us to skip layout out a function accurately. If
so, flush the type cache for both the function and struct
case to ensure that any pointers to the functions get
recomputed. This is overconservative, but with this patch
clang can build itself again.
Chris Lattner [Sun, 10 Jul 2011 05:34:54 +0000 (05:34 +0000)]
change EmitLValueForField to cast the returned lvalue to the right
type, even when in the struct case. This was one root issue that was
causing type mismatches throughout the compiler.
Chris Lattner [Sun, 10 Jul 2011 03:47:27 +0000 (03:47 +0000)]
Fix the clang bootstrap and Jay's testcase from llvm-dev by being completely
conservative when converting a functiontype to IR when in a "pointer within
a struct" context. This has the unfortunate sideeffect of compiling all
function pointers inside of structs into "{}*" which, though correct, is
ugly. This has the positive side effect of being correct, and it is pretty
straight-forward to improve on this.
Chris Lattner [Sun, 10 Jul 2011 03:38:35 +0000 (03:38 +0000)]
when emitting pointer load from an lvalue or storing to an lvalue,
do an explicit bitcast to whatever ConvertType produces. This will
go with the next patch.
Chris Lattner [Sun, 10 Jul 2011 00:18:59 +0000 (00:18 +0000)]
Rename CGT::VerifyFuncTypeComplete to isFuncTypeConvertible since
it is a predicate, not an action. Change the return type to be a bool,
not the incomplete member. Enhace it to detect the recursive compilation
case, allowing us to compile Eli's testcase on llvmdev:
struct T {
struct T (*p)(void);
} t;
into:
%struct.T = type { {}* }
@t = common global %struct.T zeroinitializer, align 8
[arcmt] Introduce new '-ccc-arcmt-migrate <path>' ARC migration driver option.
This is a new mode of migration, where we avoid modifying the original files but
we emit temporary files instead.
<path> will be used to keep migration process metadata. Currently the temporary files
that are produced are put in the system's temp directory but we can put them
in the <path> if is necessary.
Also introduce new ARC migration functions in libclang whose only purpose,
currently, is to accept <path> and provide pairs of original file/transformed file
to map from the originals to the files after transformations are applied.
Finally introduce the c-arcmt-test utility that exercises the new libclang functions,
update arcmt-test, and add tests for the whole process.
Chris Lattner [Sat, 9 Jul 2011 18:53:56 +0000 (18:53 +0000)]
when an enum type is completed, only flush the type cache when
the enum has already been converted. If not, there cannot be any types
built on top of it, so there is no need to flush the cache.
John McCall [Sat, 9 Jul 2011 09:09:00 +0000 (09:09 +0000)]
More compiler workarounds. I have to admit that I was not
expecting so much concentrated oddity on what seemed like a
trivial feature. Thanks to François Pichet for doing the
MSVC legwork here.
John McCall [Sat, 9 Jul 2011 01:37:26 +0000 (01:37 +0000)]
A number of array-related IR-gen cleanups.
- Emit default-initialization of arrays that were partially initialized
with initializer lists with a loop, rather than emitting the default
initializer N times;
- support destroying VLAs of non-trivial type, although this is not
yet exposed to users; and
- support the partial destruction of arrays initialized with
initializer lists when an initializer throws an exception.
Eli Friedman [Fri, 8 Jul 2011 23:31:17 +0000 (23:31 +0000)]
Change -mno-mmx to be more compatible with gcc. Specifically, -mno-mmx should not imply -mno-sse.
Note that because we don't usually touch the MMX registers anyway, all -mno-mmx needs to do is tweak the x86-32 calling convention a little for vectors that look like MMX vectors, and prevent the definition of __MMX__.
clang doesn't actually stop the user from using MMX inline asm operands or MMX builtins in -mno-mmx mode; as a QOI issue, it would be nice to diagnose, but I doubt it really matters much.
Eli Friedman [Fri, 8 Jul 2011 20:17:28 +0000 (20:17 +0000)]
Fix up dependency file name printing to more closely match that of gcc, including fixing a nasty recent regression that could make us print "/foo.h" with a command-line including "-I ./".
Douglas Gregor [Fri, 8 Jul 2011 15:50:43 +0000 (15:50 +0000)]
Teach CXXUnresolvedConstructExpr when it should be an
lvalue/xvalue/rvalue, rather than just (incorrectly) assuming it's an
lvalue. Fixes PR10285 / <rdar://problem/9743926>.
Add several CFG-stress-testing input source files. These use the
preprocessor to build up very large CFGs in various shapes that can
produce different algorithmic behavior in CFG-walking code.
Make the worklist in the uninitialized values checker actually a queue.
Previously, despite the names 'enqueue' and 'dequeue', it behaved as
a stack and visited blocks in a LIFO fashion. This interacts badly with
extremely broad CFGs *inside* of a loop (such as a large switch inside
a state machine) where every block updates a different variable.
When encountering such a CFG, the checker visited blocks in essentially
a "depth first" order due to the stack-like behavior of the work list.
Combined with each block updating a different variable, the saturation
logic of the checker caused it to re-traverse blocks [1,N-1] of the
broad CFG inside the loop after traversing block N. These re-traversals
were to propagate the variable values derived from block N. Assuming
approximately the same number of variables as inner blocks exist, the
end result is O(N^2) updates. By making this a queue, we also make the
traversal essentially "breadth-first" across each of the N inner blocks
of the loop. Then all of this state is propagated around to all N inner
blocks of the loop. The result is O(N) updates.
The truth is in the numbers:
Before, gcc.c: 96409 block visits (max: 61546, avg: 591)
After, gcc.c: 69958 block visits (max: 33090, avg: 429)
Before, PR10183: 2540494 block vists (max: 2536495, avg: 37360)
After, PR10183: 137803 block visits (max: 134406, avg: 2026)
The nearly 20x reduction in work for PR10183 corresponds to a roughly
100x speedup in compile time.
I've tested it on all the code I can get my hands on, and I've seen no
slowdowns due to this change. Where I've collected stats, the ammount of
work done is on average less. I'll also commit shortly some synthetic
test cases useful in analyzing the performance of CFG-based warnings.
Submitting this based on Doug's feedback that post-commit review should
be good. Ted, please review! Hopefully this helps compile times until
then.
Fix a FIXME in clang ARM driver that was exposed as a bug with ARM backend
change.
Previously clang was passing the following feature strings to the ARM backend
when CPU is cortex-a8: +neon,-vfp2,-vfp3
This used to work because -vfp2,-vfp3 had no effect after +neon. Now that the
features are controlled by individual bits (with implied hierarchy), the net
effect is all three features will be turned off.
Remove a no-op break after a return, and correct one of the most
confusing indentations I've seen recently... Just noticed these while
making a change elsewhere.
Switch the token-paste source locations inside of function style macro
argument expansion to use the macro argument source locations as well.
Add a few tests to exercise this. There is still a bit more work needed
here though.
Keep track of which source locations are part of a macro argument
instantiation and improve diagnostics which are stem from macro
arguments to trace the argument itself back through the layers of macro
expansion.
This requires some tricky handling of the source locations, as the
argument appears to be expanded in the opposite direction from the
surrounding macro. This patch provides helper routines that encapsulate
the logic and explain the reasoning behind how we step through macros
during diagnostic printing.
This fixes the rest of the test cases originially in PR9279, and later
split out into PR10214 and PR10215.
There is still some more work we can do here to improve the macro
backtrace, but those will follow as separate patches.
objc-arc: diagnose assignment/cast of a weak-unavailable
object to a __weak object/type. // rdar://9732636.
This is objc side of things. objc++ side tbd.
Douglas Gregor [Thu, 7 Jul 2011 16:03:39 +0000 (16:03 +0000)]
Introduce a new libclang aPI function,
clang_codeCompleteGetContexts(), that provides the client with
information about the context in which code completion has occurred
and what kinds of entities make sense as completions at that
point. Patch by Connor Wakamo!
John McCall [Thu, 7 Jul 2011 06:58:02 +0000 (06:58 +0000)]
In ARC, reclaim all return values of retainable type, not just those
where we have an immediate need of a retained value.
As an exception, don't do this when the call is made as the immediate
operand of a __bridge retain. This is more in the way of a workaround
than an actual guarantee, so it's acceptable to be brittle here.
Make the Preprocessor more memory efficient and improve macro instantiation diagnostics.
When a macro instantiation occurs, reserve a SLocEntry chunk with length the
full length of the macro definition source. Set the spelling location of this chunk
to point to the start of the macro definition and any tokens that are lexed directly
from the macro definition will get a location from this chunk with the appropriate offset.
For any tokens that come from argument expansion, '##' paste operator, etc. have their
instantiation location point at the appropriate place in the instantiated macro definition
(the argument identifier and the '##' token respectively).
This improves macro instantiation diagnostics:
Before:
t.c:5:9: error: invalid operands to binary expression ('struct S' and 'int')
int y = M(/);
^~~~
t.c:5:11: note: instantiated from:
int y = M(/);
^
After:
t.c:5:9: error: invalid operands to binary expression ('struct S' and 'int')
int y = M(/);
^~~~
t.c:3:20: note: instantiated from:
\#define M(op) (foo op 3);
~~~ ^ ~
t.c:5:11: note: instantiated from:
int y = M(/);
^
The memory savings for a candidate boost library that abuses the preprocessor are:
- 32% less SLocEntries (37M -> 25M)
- 30% reduction in PCH file size (900M -> 635M)
- 50% reduction in memory usage for the SLocEntry table (1.6G -> 800M)
Fix bug in SourceManager::getDecomposedInstantiationLocSlowCase.
It would add up relative (decomposed) offsets like in getDecomposedSpellingLocSlowCase, but while
it makes sense to preserve the offset among lexed spelling locations, it doesn't make
sense to add anything to the offset of the instantiation location. The instantiation
location will be the same regardless of the relative offset in the tokens that were
instantiated.
This bug didn't actually affect anything because, currently, in practice we never create macro
locations with relative offset greater than 0.
Do not violate the opencl casting rules. This test case still illustrates the problem. In the future, we should throw an error when doing invalid casting.
Sean Hunt [Wed, 6 Jul 2011 23:35:33 +0000 (23:35 +0000)]
Ensure that we actually visit function parameter declarations with
RecursiveASTVisitor.
This deficiency was discovered while working with the AST matcher
framework and likely impacts other users of RecursiveASTMatcher who
previously weren't seeing these Decls in their visitation.
Based on comments from Chris, switch to using CFG::getNumBlockIDs()
rather than a computed std::distance(). At some point I had convinced
myself that these two were different; but as far as I can tell on
re-exampination they aren't, and the number of block IDs is actually
just a count of the blocks in the CFG.
While this removes the primary motivation for guarding all of this with
CollectStats, I have a patch coming up that will almost certainly make
it important again.
Douglas Gregor [Wed, 6 Jul 2011 22:04:06 +0000 (22:04 +0000)]
Properly implement the scope restriction on the NRVO for
throw-expressions, such that we don't consider the NRVO when the
non-volatile automatic object comes from outside the innermost try
scope (C++0x [class.copymove]p13). In C++98/03, our ASTs were
incorrect but it didn't matter because IR generation doesn't actually
apply the NRVO here. In C++0x, however, we were moving from an object
when in fact we should have copied from it. Fixes PR10142 /
<rdar://problem/9714312>.
Douglas Gregor [Wed, 6 Jul 2011 17:40:26 +0000 (17:40 +0000)]
Keep track of when "unrecoverable" errors occur, then allow
clang_saveTranslationUnit() to save a PCH file if the only errors it
contains are recoverable errors. Fixes <rdar://problem/9727804>.
Build up statistics about the work done for analysis based warnings.
Special detail is added for uninitialized variable analysis as this has
serious performance problems than need to be tracked.
Computing some of this data is expensive, for example walking the CFG to
determine its size. To avoid doing that unless the stats data is going
to be used, we thread a bit into the Sema object to track whether
detailed stats should be collected or not. This bit is used to avoid
computations whereever the computations are likely to be more expensive
than checking the state of the flag. Thus, counters are in some cases
unconditionally updated, but the more expensive (and less frequent)
aggregation steps are skipped.
With this patch, we're able to see that for 'gcc.c':
*** Analysis Based Warnings Stats:
232 functions analyzed (0 w/o CFGs).
7151 CFG blocks built.
30 average CFG blocks per function.
1167 max CFG blocks per function.
163 functions analyzed for uninitialiazed variables
640 variables analyzed.
3 average variables per function.
94 max variables per function.
96409 block visits.
591 average block visits per function.
61546 max block visits per function.
And for the reduced testcase in PR10183:
*** Analysis Based Warnings Stats:
98 functions analyzed (0 w/o CFGs).
8526 CFG blocks built.
87 average CFG blocks per function.
7277 max CFG blocks per function.
68 functions analyzed for uninitialiazed variables
1359 variables analyzed.
19 average variables per function.
1196 max variables per function. 2540494 block visits.
37360 average block visits per function. 2536495 max block visits per function.
That last number is the somewhat scary one that indicates the problem in
PR10183.
projects / clang / log