- Mar 16, 2012
-
-
Benjamin Kramer authored
No functionality change. llvm-svn: 152927
-
NAKAMURA Takumi authored
lit/TestRunner.py: [Win32] Check all opened_files[] released, rather than (obsoleted) written_files[]. In previous case, RUN: foo -o %t RUN: FileCheck < %t RUN: bar -o %t 2nd read handle might prevent manipulation of 3rd %t in bar, to remove and rename. llvm-svn: 152916
-
NAKAMURA Takumi authored
We can simply confirm the handle released to open it with EXCLUSIVE. Attempting renaming was bad. llvm-svn: 152915
-
Bill Wendling authored
alignment. If that's the case, then we want to make sure that we don't increase the alignment of the store instruction. Because if we increase it to be "more aligned" than the pointer, code-gen may use instructions which require a greater alignment than the pointer guarantees. <rdar://problem/11043589> llvm-svn: 152907
-
Craig Topper authored
llvm-svn: 152906
-
Chandler Carruth authored
It was added in 2007 as the first cut at supporting no-inline attributes, but we didn't have function attributes of any form at the time. However, it was added without any mention in the LangRef or other documentation. Later on, in 2008, Devang added function notes for 'inline=never' and then turned them into proper function attributes. From that point onward, as far as I can tell, the world moved on, and no one has touched 'llvm.noinline' in any meaningful way since. It's time has now come. We have had better mechanisms for doing this for a long time, all the frontends I'm aware of use them, and this is just holding back progress. Given that it was never a documented feature of the IR, I've provided no auto-upgrade support. If people know of real, in-the-wild bitcode that relies on this, yell at me and I'll add it, but I *seriously* doubt anyone cares. llvm-svn: 152904
-
Chandler Carruth authored
directly query the function information which this set was representing. This simplifies the interface of the inline cost analysis, and makes the always-inline pass significantly more efficient. Previously, always-inline would first make a single set of every function in the module *except* those marked with the always-inline attribute. It would then query this set at every call site to see if the function was a member of the set, and if so, refuse to inline it. This is quite wasteful. Instead, simply check the function attribute directly when looking at the callsite. The normal inliner also had similar redundancy. It added every function in the module with the noinline attribute to its set to ignore, even though inside the cost analysis function we *already tested* the noinline attribute and produced the same result. The only tricky part of removing this is that we have to be able to correctly remove only the functions inlined by the always-inline pass when finalizing, which requires a bit of a hack. Still, much less of a hack than the set of all non-always-inline functions was. While I was touching this function, I switched a heavy-weight set to a vector with sort+unique. The algorithm already had a two-phase insert and removal pattern, we were just needlessly paying the uniquing cost on every insert. This probably speeds up some compiles by a small amount (-O0 compiles with lots of always-inline, so potentially heavy libc++ users), but I've not tried to measure it. I believe there is no functional change here, but yell if you spot one. None are intended. Finally, the direction this is going in is to greatly simplify the inline cost query interface so that we can replace its implementation with a much more clever one. Along the way, all the APIs get simplified, so it seems incrementally good. llvm-svn: 152903
-
Craig Topper authored
Const-correct the FixedLenDecoderEmitter. Pass a few things by const reference instead of value to avoid some copying. llvm-svn: 152899
-
Chandler Carruth authored
analysis implementation. The header was already separated. Also cleanup all the comments in the header to follow a nice modern doxygen form. There is still plenty of cruft here, but some of that will fall out in subsequent refactorings and this was an easy step in the right direction. No functionality changed here. llvm-svn: 152898
-
Andrew Trick authored
These edges are not really necessary, but it is consistent with the way we currently create physreg edges. Scheduler heuristics that expect a DAG edge to the block terminator could benefit from this change. Although in the future I hope we have a better mechanism for modeling latency across scheduling regions. llvm-svn: 152895
-
Andrew Trick authored
Only record IVUsers that are dominated by simplified loop headers. Otherwise SCEVExpander will crash while looking for a preheader. I previously tried to work around this in LSR itself, but that was insufficient. This way, LSR can continue to run if some uses are not in simple loops, as long as we don't attempt to analyze those users. Fixes <rdar://problem/11049788> Segmentation fault: 11 in LoopStrengthReduce llvm-svn: 152892
-
Craig Topper authored
Spacing fixes. Mostly aligning arguments that spilled onto next line with the opening parenthese instead of 2 spaces in. llvm-svn: 152889
-
Chad Rosier authored
on our internal nightly testers. So, basically revert r152486 again. Abbreviated original commit message: Implement a more intelligent way of spilling uses across an invoke boundary. It looks as if Chander's inlining work, r152737, exposed an issue. llvm-svn: 152887
-
Craig Topper authored
Remove unused field NumVariable from Filter class. Even it was needed the same result could be found with VariableInstructions.size(). Also fix some typos in comments. llvm-svn: 152885
-
Eli Friedman authored
In InstCombiner::visitOr, make sure we reverse the operand swap used for checking for or-of-xor operations after those checks; a later check expects that any constant will be in Op1. PR12234. llvm-svn: 152884
-
Jim Grosbach authored
rdar://11058464 llvm-svn: 152883
-
Jim Grosbach authored
rdar://11058464 llvm-svn: 152881
-
Eric Christopher authored
Patch by Clemens Hammacher! Fixes PR12243 llvm-svn: 152880
-
NAKAMURA Takumi authored
Revert r152613 (and r152614), "Inline the d'tor and add an anchor instead." for workaround of g++-4.4's miscompilation. It caused MSP430DAGToDAGISel::SelectIndexedBinOp() to be miscompiled. When two ReplaceUses()'s are expanded as inline, vtable in base class is stored to latter (ISelUpdater)ISU. llvm-svn: 152877
-
Eric Christopher authored
the DECL information. rdar://10855921 llvm-svn: 152876
-
Jim Grosbach authored
llvm-svn: 152870
-
- Mar 15, 2012
-
-
Chad Rosier authored
and still allow immediate encoding, just not with cmn. rdar://11038907 llvm-svn: 152869
-
Daniel Dunbar authored
the test-suite. llvm-svn: 152860
-
Chad Rosier authored
rdar://11038907 llvm-svn: 152847
-
Jim Grosbach authored
rdar://11056591 llvm-svn: 152846
-
Eric Christopher authored
Part of rdar://8905263 llvm-svn: 152845
-
Eric Christopher authored
llvm-svn: 152844
-
Eric Christopher authored
llvm-svn: 152843
-
Eric Christopher authored
llvm-svn: 152842
-
Eric Christopher authored
llvm-svn: 152841
-
Jakob Stoklund Olesen authored
llvm-svn: 152840
-
Jim Grosbach authored
rdar://11056647 llvm-svn: 152834
-
Jakob Stoklund Olesen authored
We currently assume that all targets have less than 64k opcodes. We shouldn't limit it further. llvm-svn: 152833
-
Matt Beaumont-Gay authored
llvm-svn: 152832
-
Duncan Sands authored
theoretical fix since it only matters for types with >= 2^63 bits (!) and also only matters if pointers have more than 64 bits, which is not supported anyway. llvm-svn: 152831
-
Lang Hames authored
register allocation by allowing all 32 D-registers to be used. Patch by Cameron Zwarich. llvm-svn: 152824
-
Jakob Stoklund Olesen authored
We cannot limit the concatenated instruction names to 64K. ARM is already at 32K, and it is easy to imagine a target with more instructions. llvm-svn: 152817
-
Jakob Stoklund Olesen authored
This patch limited the concatenated register names to 64K which meant that the total number of registers was many times less than 64K. If any compilers actually enforce the 64K limit on string literals, and it turns out to be a problem, we should fix that problem by not using long string literals. llvm-svn: 152816
-
Kristof Beyls authored
Fix VCVT decoding (between floating-point and fixed-point, Floating-point). Patch by Richard Barton. llvm-svn: 152814
-
Michael J. Spencer authored
llvm-svn: 152812
-