- Feb 12, 2013
-
-
Krzysztof Parzyszek authored
option "generate-dwarf-pubnames" to control it, set to "false" by default. llvm-svn: 174981
-
Sergei Larin authored
Equal treatment of labels and other terminators in MI DAG construction. MI sched DAG construction allows targets to include terminators into scheduling DAG. Extend this functionality to labels as well. llvm-svn: 174977
-
Paul Redmond authored
DAGCombiner::ReduceLoadWidth was converting (trunc i32 (shl i64 v, 32)) into (shl i32 v, 32) into undef. To prevent this, check the shift count against the final result size. Patch by: Kevin Schoedel Reviewed by: Nadav Rotem llvm-svn: 174972
-
Cameron Zwarich authored
live range after inserting a copy at the end of a block. llvm-svn: 174945
-
Cameron Zwarich authored
llvm-svn: 174944
-
Cameron Zwarich authored
particularly useful for catching issues with architectures that have exotic terminators like MIPS. llvm-svn: 174938
-
Cameron Zwarich authored
a critical edge. llvm-svn: 174936
-
Cameron Zwarich authored
live ranges should always be extended, and the only successor that should be considered for extension of other ranges is the target of the split edge. llvm-svn: 174935
-
Pete Cooper authored
Sorry for the lack of a test case. I tried writing one for i386 as i know selects are illegal on this target, but they are actually considered legal by isel and expanded later. I can't see any targets to trigger this, but checking for the legality of a node before forming it is general goodness. llvm-svn: 174934
-
- Feb 11, 2013
-
-
Cameron Zwarich authored
This is currently a bit hairier than it needs to be, since depending on where the split block resides the end ListEntry of the split block may be the end ListEntry of the original block or a new entry. Some changes to the SlotIndexes updating should make it possible to eliminate the two cases here. This also isn't as optimized as it could be. In the future Liveinterval should probably get a flag that indicates whether the LiveInterval is within a single basic block. We could ignore all such intervals when splitting an edge. llvm-svn: 174870
-
Cameron Zwarich authored
really trying to avoid piping SlotIndexes through to RemoveBranch() and friends. llvm-svn: 174869
-
Bob Wilson authored
This reverts my commit 171047. Now that I've removed my misguided attempt to support backend warnings, these diagnostics are only about inline assembly. It would take quite a bit more work to generalize them properly, so I'm just reverting this. llvm-svn: 174860
-
Evan Cheng authored
function is successfully handled by fast-isel. That's because function arguments are *always* handled by SDISel. Introduce FastLowerArguments to allow each target to provide hook to handle formal argument lowering. As a proof-of-concept, add ARMFastIsel::FastLowerArguments to handle functions with 4 or fewer scalar integer (i8, i16, or i32) arguments. It completely eliminates the need for SDISel for trivial functions. rdar://13163905 llvm-svn: 174855
-
Evan Cheng authored
llvm-svn: 174854
-
Cameron Zwarich authored
support for updating SlotIndexes to MachineBasicBlock::SplitCriticalEdge(). This calls renumberIndexes() every time; it should be improved to only renumber locally. llvm-svn: 174851
-
Cameron Zwarich authored
both LiveVariables and LiveIntervals. llvm-svn: 174850
-
- Feb 10, 2013
-
-
Cameron Zwarich authored
present, it currently verifies them with the MachineVerifier, and this passed all of the test cases in 'make check' (when accounting for existing verifier errors). There were some assertion failures in the two-address pass, but they also happened on code without phis and look like they are caused by different kill flags from LiveIntervals. The only part that doesn't work is the critical edge splitting heuristic, because there isn't currently an efficient way to update LiveIntervals after splitting an edge. I'll probably start by implementing the slow fallback and test that it works before tackling the fast path for single-block ranges. The existing code that updates LiveVariables is fairly slow as it is. There isn't a command-line option for enabling this; instead, just edit PHIElimination.cpp to require LiveIntervals. llvm-svn: 174831
-
Cameron Zwarich authored
llvm-svn: 174830
-
Cameron Zwarich authored
make sense anymore. llvm-svn: 174829
-
Cameron Zwarich authored
llvm-svn: 174828
-
- Feb 09, 2013
-
-
Jakub Staszak authored
llvm-svn: 174817
-
Manman Ren authored
line table entries in assembly. llvm-svn: 174785
-
Jakob Stoklund Olesen authored
This is part of the plan to delete LiveVariables. llvm-svn: 174783
-
Jakob Stoklund Olesen authored
This uses a liveness algorithm that does not depend on data from the LiveVariables analysis, it is the first step towards removing LiveVariables completely. llvm-svn: 174774
-
- Feb 08, 2013
-
-
rdar://problem/12867368Bob Wilson authored
This reverts r171041. This was a nice idea that didn't work out well. Clang warnings need to be associated with warning groups so that they can be selectively disabled, promoted to errors, etc. This simplistic patch didn't allow for that. Enhancing it to provide some way for the backend to specify a front-end warning type seems like overkill for the few uses of this, at least for now. llvm-svn: 174748
-
Hal Finkel authored
Previously, even when a pre-increment load or store was generated, we often needed to keep a copy of the original base register for use with other offsets. If all of these offsets are constants (including the offset which was combined into the addressing mode), then this is clearly unnecessary. This change adjusts these other offsets to use the new incremented address. llvm-svn: 174746
-
Bob Wilson authored
Aside from the question of whether we report a warning or an error when we can't satisfy a requested stack object alignment, the current implementation of this is not good. We're not providing any source location in the diagnostics and the current warning is not connected to any warning group so you can't control it. We could improve the source location somewhat, but we can do a much better job if this check is implemented in the front-end, so let's do that instead. <rdar://problem/13127907> llvm-svn: 174741
-
Arnold Schwaighofer authored
Adds a function to target transform info to query for the cost of address computation. The cost model analysis pass now also queries this interface. The code in LoopVectorize adds the cost of address computation as part of the memory instruction cost calculation. Only there, we know whether the instruction will be scalarized or not. Increase the penality for inserting in to D registers on swift. This becomes necessary because we now always assume that address computation has a cost and three is a closer value to the architecture. radar://13097204 llvm-svn: 174713
-
- Feb 07, 2013
-
-
Eric Christopher authored
syms before constructing the compile units so we're not emitting section references to sections not there already. llvm-svn: 174663
-
- Feb 06, 2013
-
-
Eric Christopher authored
units coming in. llvm-svn: 174548
-
Eric Christopher authored
llvm-svn: 174547
-
Evan Cheng authored
llvm-svn: 174482
-
Manman Ren authored
Failure: undefined symbol 'Lline_table_start0'. Root-cause: we use a symbol subtraction to calculate at_stmt_list, but the line table entries are not dumped in the assembly. Fix: use zero instead of a symbol subtraction for Compile Unit 0. llvm-svn: 174479
-
- Feb 05, 2013
-
-
Manman Ren authored
We generate one line table for each compilation unit in the object file. Reviewed by Eric and Kevin. rdar://problem/13067005 llvm-svn: 174445
-
Owen Anderson authored
Reapply r174343, with a fix for a scary DAG combine bug where it failed to differentiate between the alignment of the base point of a load, and the overall alignment of the load. This caused infinite loops in DAG combine with the original application of this patch. ORIGINAL COMMIT LOG: When the target-independent DAGCombiner inferred a higher alignment for a load, it would replace the load with one with the higher alignment. However, it did not place the new load in the worklist, which prevented later DAG combines in the same phase (for example, target-specific combines) from ever seeing it. This patch corrects that oversight, and updates some tests whose output changed due to slightly different DAGCombine outputs. llvm-svn: 174431
-
Jakob Stoklund Olesen authored
All targets are now adding return value registers as implicit uses on return instructions, and there is no longer a need for the live out lists. llvm-svn: 174417
-
Jakob Stoklund Olesen authored
Now that return value registers are return instruction uses, there is no need for special treatment of return blocks. llvm-svn: 174416
-
NAKAMURA Takumi authored
It caused hangups in compiling clang/lib/Parse/ParseDecl.cpp and clang/lib/Driver/Tools.cpp in stage2 on some hosts. llvm-svn: 174374
-
Eric Christopher authored
for the first compile unit. llvm-svn: 174352
-
Eric Christopher authored
DWARF5 split dwarf proposal. llvm-svn: 174350
-