- Nov 18, 2013
-
-
Alexander Kornienko authored
Fixes http://llvm.org/PR16221, http://llvm.org/PR15927 Phabricator: http://llvm-reviews.chandlerc.com/D1236 Patch by Andrew Tulloch! llvm-svn: 195016
-
Alexey Samsonov authored
[ASan] Fix PR17867 - make sure ASan doesn't crash if use-after-scope and use-after-return are combined. llvm-svn: 195014
-
NAKAMURA Takumi authored
llvm-svn: 195010
-
Arnold Schwaighofer authored
In some case the loop exit count computation can overflow. Extend the type to prevent most of those cases. The problem is loops like: int main () { int a = 1; char b = 0; lbl: a &= 4; b--; if (b) goto lbl; return a; } The backedge count is 255. The induction variable type is i8. If we add one to 255 to get the exit count we overflow to zero. To work around this issue we extend the type of the induction variable to i32 in the case of i8 and i16. PR17532 llvm-svn: 195008
-
Daniel Sanders authored
Fixed an inappropriate use of BuildPairF64 when compiling for MIPS32 with FP64 which resulted in an impossible constraint on the register allocation. It now uses BuildPairF64_64. llvm-svn: 195007
-
Matheus Almeida authored
Note that there's no hardware yet that relies on that encoding. llvm-svn: 195006
-
Matheus Almeida authored
The immediate field should be encoded as "imm - 1" as the CPU always adds one to that field. llvm-svn: 195004
-
Alexey Samsonov authored
llvm-svn: 195003
-
Daniel Sanders authored
llvm-svn: 195001
-
Arnaud A. de Grandmaison authored
libtool sets RPATH to "$ORIGIN/../lib:/the/directory/where/it/was/built/lib" so that a developper can use the built or the installed version seamlessly. Our binary packages should not have this developer friendly tweak, as the users of the binaries will not have the build tree. Beside, in case the development tree is a possibly on an automounted share, this can create very bad user experience : they will incur an automount timeout penalty and will get a very bad feeling of llvm/clang's speed. llvm-svn: 194999
-
Alexey Samsonov authored
llvm-svn: 194998
-
Alexey Samsonov authored
This change is incorrect. If you delete virtual destructor of both a base class and a subclass, then the following code: Base *foo = new Child(); delete foo; will not cause the destructor for members of Child class. As a result, I observe plently of memory leaks. Notable examples I investigated are: ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl. llvm-svn: 194997
-
Kevin Qin authored
Set some unspecified bits of INS/DUP to zero as ARMARM requested. llvm-svn: 194996
-
Hao Liu authored
The functions are like: vst1_s8_x2 ... llvm-svn: 194990
-
Manman Ren authored
Debug info verifier is part of the verifier which is a Function Pass. Tot currently tries to pull all reachable debug info MDNodes in each function, which is too time-consuming. The correct fix seems to be separating debug info verification to its own module pass. I will disable the debug info verifier until a correct fix is found. For Bill's testing case, enabling debug info verifier increase compile time from 11s to 11m. llvm-svn: 194986
-
Matt Arsenault authored
llvm-svn: 194985
-
- Nov 17, 2013
-
-
David Blaikie authored
llvm-svn: 194981
-
David Blaikie authored
llvm-svn: 194980
-
David Blaikie authored
llvm-svn: 194979
-
Ahmed Bougacha authored
llvm-svn: 194978
-
Ahmed Bougacha authored
llvm-svn: 194977
-
Ahmed Bougacha authored
llvm-svn: 194976
-
Manman Ren authored
llvm-svn: 194975
-
Manman Ren authored
We used to collect debug info MDNodes in doInitialization and verify them in doFinalization. That is incorrect since MDNodes can be modified by passes run between doInitialization and doFinalization. To fix the problem, we handle debug info MDNodes that can be reached from a function in runOnFunction (i.e we collect those nodes by calling processDeclare, processValue and processLocation, and then verify them in runOnFunction). We handle debug info MDNodes that can be reached from named metadata in doFinalization. This is in line with how Verifier handles module-level data (they are verified in doFinalization). rdar://15472296 llvm-svn: 194974
-
Manman Ren authored
We used to depend on running processModule before the other public functions such as processDeclare, processValue and processLocation. We are now relaxing the constraint by adding a module argument to the three functions and letting the three functions to initialize the type map. This will be used in a follow-on patch that collects nodes reachable from a Function. llvm-svn: 194973
-
NAKAMURA Takumi authored
eraseFromParent() invalidates OldName. llvm-svn: 194970
-
Hal Finkel authored
This adds a boolean member variable to the PassManagerBuilder to control loop rerolling (just like we have for unrolling and the various vectorization options). This is necessary for control by the frontend. Loop rerolling remains disabled by default at all optimization levels. llvm-svn: 194966
-
Anders Waldenborg authored
Check should be for pointer being NULL, not what it points to. Also adds a test for this case. Reviewed By: indygreg Differential Revision: http://llvm-reviews.chandlerc.com/D1878 llvm-svn: 194965
-
Anders Waldenborg authored
As the "LLVMInitializeAll*" functions are not available as symbols in the shared library they can't be used, and as a workaround a list of the targets is kept and the individual symbols tried. As soon as the "All"-functions are changed to proper symbols (as opposed to static inlines in the headers) this hack will be replace with simple calls to the corresponding "LLVMInitializeAll*" functions. Reviewed By: indygreg CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1879 llvm-svn: 194964
-
Alp Toker authored
llvm-svn: 194962
-
Bill Wendling authored
llvm-svn: 194961
-
Bill Wendling authored
This reverts commit f1d9fe9d04ce93f6d5dcebbd2cb6a07414d7a029. This was causing PR17964. We need to use thread data before regular data. llvm-svn: 194960
-
Benjamin Kramer authored
llvm-svn: 194959
-
Yaron Keren authored
This patch modifies LineCol to be a uint32_t. See http://llvm.org/bugs/show_bug.cgi?id=17957 llvm-svn: 194957
-
Michael Gottesman authored
[block-freq] Add BlockFrequency::scale that returns a remainder from the division and make the private scale in BlockFrequency more performant. This change is the first in a series of changes improving LLVM's Block Frequency propogation implementation to not lose probability mass in branchy code when propogating block frequency information from a basic block to its successors. This patch is a simple infrastructure improvement that does not actually modify the block frequency algorithm. The specific changes are: 1. Changes the division algorithm used when scaling block frequencies by branch probabilities to a short division algorithm. This gives us the remainder for free as well as provides a nice speed boost. When I benched the old routine and the new routine on a Sandy Bridge iMac with disabled turbo mode performing 8192 iterations on an array of length 32768, I saw ~600% increase in speed in mean/median performance. 2. Exposes a scale method that returns a remainder. This is important so we can ensure that when we scale a block frequency by some branch probability BP = N/D, the remainder from the division by D can be retrieved and propagated to other children to ensure no probability mass is lost (more to come on this). llvm-svn: 194950
-
Chandler Carruth authored
AnalysisManager. All this method did was assert something and we have a perfectly good way to trigger that assert from the query path. llvm-svn: 194947
-
Matt Arsenault authored
llvm-svn: 194945
-
Matt Arsenault authored
llvm-svn: 194944
-
Hal Finkel authored
Generally speaking, control flow paths with error reporting calls are cold. So far, error reporting calls are calls to perror and calls to fprintf, fwrite, etc. with stderr as the stream. This can be extended in the future. The primary motivation is to improve block placement (the cold attribute affects the static branch prediction heuristics). llvm-svn: 194943
-
Andrew Trick authored
Implementing this on bigendian platforms could get strange. I added a target hook, getStackSlotRange, per Jakob's recommendation to make this as explicit as possible. llvm-svn: 194942
-