- Nov 19, 2012
-
-
Bob Wilson authored
This patch moves the isInlineViable function from the InlineAlways pass into the InlineCostAnalyzer and then changes the InlineCost computation to use that simple check for always-inline functions. All the special-case checks for AlwaysInline in the CallAnalyzer can then go away. llvm-svn: 168300
-
Bob Wilson authored
llvm-svn: 168299
-
Chandler Carruth authored
There were numerous issues here that were all entangled, and so I've tried to do a general simplification of the logic. 1) The logic was mimicing actual GCC bugs, rather than "features". These have been fixed in trunk GCC, and this fixes Clang as well. Notably, the logic was always intended to be last-match-wins like any other flag. 2) The logic for handling '-mdynamic-no-pic' was preposterously unclear. It also allowed the use of this flag on non-Darwin platforms where it has no actual meaning. Now this option is handled directly based on tests of how llvm-gcc behaves, and it is only supported on Darwin. 3) The APIs for the Driver's ToolChains had the implementation ugliness of dynamic-no-pic leaking through them. They also had the implementation details of the LLVM relocation model flag names leaking through. 4) The actual results of passing these flags was incorrect on Darwin in many cases. For example, Darwin *always* uses PIC level 2 if it uses in PIC level, and Darwin *always* uses PIC on 64-bit regardless of the flags specified, including -fPIE. Darwin never compiles in PIE mode, but it can *link* in PIE mode. 5) Also, PIC was not always being enabled even when PIE was. This isn't a supported mode at all and may have caused some fallout in builds with complex PIC and PIE interactions. The result is (I hope) cleaner and clearer for readers. I've also left comments and tests about some of the truly strage behavior that is observed on Darwin platforms. We have no real testing of Windows platforms and PIC, but I don't have the tools handy to figure that out. Hopefully others can beef up our testing here. Unfortunately, I can't test this for every platform. =/ If folks have dependencies on these flags that aren't covered by tests, they may break. I've audited and ensured that all the changes in behavior of the existing tests are intentional and good. In particular I've tried to make sure the Darwin behavior (which is more suprising than the Linux behavior) also matches that of 'gcc' on my mac. llvm-svn: 168297
-
Chandler Carruth authored
llvm-svn: 168296
-
NAKAMURA Takumi authored
With this, ARCMT tests would not crash on certain hosts with g++ -O2, eg. cygwin g++-4.5.3. r160404 crashed mingw32-g++-4.4.0. I guess method's pointer in conditional expression could not be handled. llvm-svn: 168295
-
Craig Topper authored
llvm-svn: 168294
-
- Nov 18, 2012
-
-
Dmitri Gribenko authored
llvm-svn: 168293
-
Duncan Sands authored
removed in commit 168035, but I missed this bit). llvm-svn: 168292
-
Duncan Sands authored
operands of the expression being written was wrongly thought to be reusable as an inner node of the expression resulting in it turning up as both an inner node *and* a leaf, creating a cycle in the def-use graph. This would have caused the verifier to blow up if things had gotten that far, however it managed to provoke an infinite loop first. llvm-svn: 168291
-
Dmitri Gribenko authored
llvm-svn: 168290
-
Dmitri Gribenko authored
llvm-svn: 168289
-
Dmitri Gribenko authored
llvm-svn: 168288
-
Dmitri Gribenko authored
llvm-svn: 168286
-
Dmitri Gribenko authored
llvm-svn: 168285
-
Andrew Trick authored
llvm-svn: 168283
-
NAKAMURA Takumi authored
XFAIL(s) can be removed. llvm-svn: 168282
-
NAKAMURA Takumi authored
llvm-svn: 168281
-
Nick Lewycky authored
llvm-svn: 168280
-
Sebastian Pop authored
as suggested by Sven Verdoolaege <skimo-polly@kotnet.org> llvm-svn: 168279
-
NAKAMURA Takumi authored
llvm-svn: 168278
-
Dmitri Gribenko authored
We actually used to assert on this. Thanks to NAKAMURA Takumi for noticing this! llvm-svn: 168277
-
Dmitri Gribenko authored
llvm-svn: 168276
-
Sean Silva authored
Some variables in code examples were not LikeThis. llvm-svn: 168275
-
- Nov 17, 2012
-
-
Andy Gibbs authored
llvm-svn: 168274
-
Benjamin Kramer authored
llvm-svn: 168273
-
Benjamin Kramer authored
llvm-svn: 168272
-
Sean Silva authored
llvm-svn: 168271
-
Fariborz Jahanian authored
of a deprecated method in original class (or category), only in overrides. // rdar://12717705 llvm-svn: 168270
-
Nico Weber authored
This makes LexCharConstant() look more like LexStringLiteral(), which doesn't have this bug. Add tests for eof after \ for several other cases. llvm-svn: 168269
-
Andy Gibbs authored
__has_attribute, __has_extension, making them behave more akin to conventional macros. llvm-svn: 168268
-
Andy Gibbs authored
llvm-svn: 168267
-
Andy Gibbs authored
common LexStringLiteral function. In doing so, some consistency problems have been ironed out (e.g. where the first token in the string literal was lexed with macro expansion, but subsequent ones were not) and also an erroneous diagnostic has been corrected. LexStringLiteral is complemented by a FinishLexStringLiteral function which can be used in the situation where the first token of the string literal has already been lexed. llvm-svn: 168266
-
Andy Gibbs authored
llvm-svn: 168265
-
James Molloy authored
llvm-svn: 168263
-
James Molloy authored
Add a new function to ConstantExpr - getAsInstruction. This returns its Instruction* corollary, which may be useful if a user wishes to transform a ConstantExpr so that one of its operands is no longer constant. llvm-svn: 168262
-
Benjamin Kramer authored
Also fixes a bit/byte mismatch when checking if a target supports atomic ops of a certain size. llvm-svn: 168260
-
Benjamin Kramer authored
llvm-svn: 168259
-
Benjamin Kramer authored
It's also simpler to just copy the words than mangling bits like this ctor did. llvm-svn: 168258
-
Ted Kremenek authored
Further reduce "-fsyntax-only -Wuninitialized" time on sqlite3.c by another 2.5% using intelligent pruning of blocks during the final reporting pass. llvm-svn: 168257
-
Pawel Wodnicki authored
llvm-svn: 168256
-