This combines two small changes:
1) Put a penalty on breaking after "<"
2) Only produce a hanging indent when parameters are separated by
commas.
Before:
aaaaaaaaaaaaaaaaaaaaaaaa<
aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa>(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
aaaaaa(new Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa));
After:
aaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa>(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
aaaaaa(new Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa));
This changes one ObjC test, but AFAICT this is not according to any
style guide (neither before nor after). We probably should be aligning
on the ":" there according to:
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Method_Invocations#Method_Invocations
llvm-svn: 173457
This warning fires on:
Operator::~Operator() {
llvm_unreachable("should never destroy an Operator");
}
That seems like a false positive. I don't see any good way to silence
the warning here, so I'm disabling it.
llvm-svn: 173455
Only for integers, pointers, and vectors of those. No floats.
Instrumentation seems very heavy, and may need to be replaced
with some approximation in the future.
llvm-svn: 173452
with an initial number of elements, instead of DenseMap, which has
zero initial elements, in order to avoid the copying of elements
when the size changes and to avoid allocating space every time
LegalizeTypes is run. This patch will not affect the memory footprint,
because DenseMap will increase the element size to 64
when the first element is added.
Patch by Wan Xiaofei.
llvm-svn: 173448
Otherwise, really long nested name specifiers can easily lead to a
violation of the column limit.
Not sure about the rules for indentation in those cases, so input is
appreciated (see tests.).
llvm-svn: 173438
Maintain separate per-node and per-tree book-keeping.
Track all instructions above a DAG node including nested subtrees.
Seperately track instructions within a subtree.
Record subtree parents.
llvm-svn: 173426
with -target i686-win32, you will see;
debug-info-static-member.cpp:11:22: error: in-class initializer for static data member of type 'const float' requires 'constexpr' specifier [-Wstatic-float-init]
const static float const_b = 3.14;
^ ~~~~
constexpr
llvm-svn: 173418
loops over instructions in the basic block or the use-def list of the
value, neither of which are really efficient when repeatedly querying
about values in the same basic block.
What's more, we already know that the CondBB is small, and so we can do
a much more efficient test by counting the uses in CondBB, and seeing if
those account for all of the uses.
Finally, we shouldn't blanket fail on any such instruction, instead we
should conservatively assume that those instructions are part of the
cost.
Note that this actually fixes a bug in the pass because
isUsedInBasicBlock has a really terrible bug in it. I'll fix that in my
next commit, but the fix for it would make this code suddenly take the
compile time hit I thought it already was taking, so I wanted to go
ahead and migrate this code to a faster & better pattern.
The bug in isUsedInBasicBlock was also causing other tests to test the
wrong thing entirely: for example we weren't actually disabling
speculation for floating point operations as intended (and tested), but
the test passed because we failed to speculate them due to the
isUsedInBasicBlock failure.
llvm-svn: 173417
and split it out of -Wgnu into its own warning flag.
* In C++11, this is now a hard error (GCC has no extension here in C++11 mode).
The error can be disabled with -Wno-static-float-init, and has a fixit to
add 'constexpr'.
* In C++98, this is still an ExtWarn, but is now controlled by
-Wstatic-float-init as well as -Wgnu.
llvm-svn: 173414
Change the GDBRemoteRegisterContext::AddRegister function to take
its RegisterInfo argument by value instead of using a reference -
it will modify the object and modifying the contents of the
g_register_infos table in GDBRemoteRegisterContext.cpp can cause a
crash the next time we step through it.
llvm-svn: 173406
AST reader.
The global module index tracks all of the identifiers known to a set
of module files. Lookup of those identifiers looks first in the global
module index, which returns the set of module files in which that
identifier can be found. The AST reader only needs to look into those
module files and any module files not known to the global index (e.g.,
because they were (re)built after the global index), reducing the
number of on-disk hash tables to visit. For an example source I'm
looking at, we go from 237844 total identifier lookups into on-disk
hash tables down to 126817.
Unfortunately, this does not translate into a performance advantage.
At best, it's a wash once the global module index has been built, but
that's ignore the cost of building the global module index (which
is itself fairly large). Profiles show that the global module index
code is far less efficient than it should be; optimizing it might give
enough of an advantage to justify its continued inclusion.
llvm-svn: 173405
Daniel Jasper