domtree. When finding a nearest common dominator, if neither A dominates
B nor B dominates A, we immediately resorted to a tree walk. The tree
walk here is *particularly* expensive because we have to build
a (potentially very large) set for one side's dominators and compare it
with the other side's.
If at any point we have DFS info, we don't need to do any of this. We
can just walk up one side's immediate dominators and return the first
one which dominates the other side. Because of the DFS info, the
dominates queries are trivially constant time.
This reduces the optimizers time in the test case on PR19499 by 70%. It
now optimizes in about 30 seconds for me. And there is still more to be
done for this case.
llvm-svn: 207406
abort while configuring if doxygen could not be found. This
is desirable because if the build is going to fail then it should
fail as early as possible.
llvm-svn: 207404
by avoiding inlining massive switches merely because they have no
instructions in them. These switches still show up where we fail to form
lookup tables, and in those cases they are actually going to cause
a very significant code size hit anyways, so inlining them is not the
right call. The right way to fix any performance regressions stemming
from this is to enhance the switch-to-lookup-table logic to fire in more
places.
This makes PR19499 about 5x less bad. It uncovers a second compile time
problem in that test case that is unrelated (surprisingly!).
llvm-svn: 207403
TestLldbGdbServer now supports both lldb-gdbserver (llgs) and
debugserver tests. Similar to the dsym/dwarf tests, they allow
running the same underlying gdb remote protocol tests against
lldb-gdbserver and debugserver. This will help make sure the
protocol-level tests for lldb-gdbserver faithfully represent
what debugserver does on OS X.
Switched back gdb remote protocol test logging to warning
and above (accidentally submitted it at debug level in a
recent commit).
llvm-svn: 207395
It's possible that the "comment AST" may be replaced or split out in the
midterm, any anyway this makes the headers easier to read.
Developers don't currently need to include "clang-c/Documentation.h" explicitly
and there's no macro to test for availability yet.
The raw comment and brief comment accessors have been kept in Index.h though
brief support may also move here as a separate proposal.
This is not a deprecation, just a gentle separation of concerns as we look to
simplify the built-in representation of comment nodes and support external
comment processors.
llvm-svn: 207392
odd to have the output of 'llvm-ar tv' depend on the format of
TimeValue::str(), but that's what we have today. If anyone needs the
output to remain compatible with GNU ar or old versions of llvm-ar, just
shout and I'll switch the code to manually format its times.
Note that there isn't a portable format -- Mac and GNU have different
formats at least (thanks Rafael!) so...
llvm-svn: 207387
Libraries specify enabled/disabled features using macro defs of 0/1, in such cases the -Wconstant-logical-operand
is noise.
rdar://15410291
llvm-svn: 207386
each line. This is particularly nice for tracking which run of
a particular pass over a particular function was slow.
This also required making the TimeValue string much more useful. First,
there is a standard format for writing out a date and time. Let's use
that rather than strings that would have to be parsed. Second, actually
output the nanosecond resolution that timevalue claims to have.
This is proving useful working on PR19499, so I figured it would be
generally useful to commit.
llvm-svn: 207385
entry. This is in preparation for generic DW_OP_piece support.
No functional change so far.
http://reviews.llvm.org/D3373
rdar://problem/15928306
llvm-svn: 207368
Only the object streamers need to track if a symbol should be marked thumb or
not. This ports the ELF case. The COFF case is not ported since it is currently
not working for some other reason (I will report a bug).
llvm-svn: 207366
* It is better if we leave third parties to do "independent" benchmark.
* We compare Clang (version unspecified) with gcc 4.0 or 4.2.
* The graphs have not been updated for a while.
* Clang is well known now. I don't think we still need to explain why
Clang is great.
llvm-svn: 207358
Benjamin Kramer