| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
|  | 
llvm-svn: 88742
 | 
| | 
| 
| 
|  | 
llvm-svn: 88738
 | 
| | 
| 
| 
|  | 
llvm-svn: 88737
 | 
| | 
| 
| 
|  | 
llvm-svn: 88734
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When splitting an edge after a machine basic block with fall-through, we
forgot to insert a jump instruction. Fix this by calling updateTerminator() on
the fall-through block when relevant.
Also be more precise in PHIElimination::isLiveIn.
llvm-svn: 88728
 | 
| | 
| 
| 
|  | 
llvm-svn: 88727
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
inserted into the numbering.
PreAllocSplitting is now using this API to insert code.
llvm-svn: 88725
 | 
| | 
| 
| 
|  | 
llvm-svn: 88719
 | 
| | 
| 
| 
|  | 
llvm-svn: 88716
 | 
| | 
| 
| 
| 
| 
|  | 
got ghost linkage. It's better than aborting.
llvm-svn: 88715
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The BasicBlock associated with a MachineBasicBlock does not necessarily
correspond to the code in the MBB.
Don't insert a new IR BasicBlock when splitting critical edges. We are not
supposed to modify the IR during codegen, and we should be able to do just
fine with a NULL BB.
llvm-svn: 88707
 | 
| | 
| 
| 
|  | 
llvm-svn: 88706
 | 
| | 
| 
| 
|  | 
llvm-svn: 88705
 | 
| | 
| 
| 
|  | 
llvm-svn: 88704
 | 
| | 
| 
| 
|  | 
llvm-svn: 88703
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
target-specific AsmPrinters.  Not all comments need DebugInfo.
Re-enable the line numbers comment test.
llvm-svn: 88697
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
code-size win, and not when it's only likely to be code-size neutral,
such as when only a single instruction would be eliminated and a new
branch would be required.
This fixes rdar://7392894.
llvm-svn: 88692
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
D0<def,dead> = ...
...
             = S0<use, kill>
S0<def>      = ...
...
D0<def>      = 
The first D0 def is correctly marked dead, however, livevariables should have
added an implicit def of S0 or we end up with a use without a def.
llvm-svn: 88690
 | 
| | 
| 
| 
| 
| 
|  | 
along the critical path.
llvm-svn: 88682
 | 
| | 
| 
| 
| 
| 
|  | 
because the testcase is triggering one more bug.
llvm-svn: 88674
 | 
| | 
| 
| 
|  | 
llvm-svn: 88672
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
one into
"a" + 0.
llvm-svn: 87084
 | 
| | 
| 
| 
|  | 
llvm-svn: 87070
 | 
| | 
| 
| 
|  | 
llvm-svn: 87069
 | 
| | 
| 
| 
|  | 
llvm-svn: 87068
 | 
| | 
| 
| 
| 
| 
|  | 
PPC is such a target; make it work.
llvm-svn: 87060
 | 
| | 
| 
| 
|  | 
llvm-svn: 87059
 | 
| | 
| 
| 
|  | 
llvm-svn: 87058
 | 
| | 
| 
| 
|  | 
llvm-svn: 87056
 | 
| | 
| 
| 
|  | 
llvm-svn: 87054
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Provide special isLoadFromStackSlotPostFE and isStoreToStackSlotPostFE
interfaces to explicitly request checking for post-frame ptr elimination
operands.  This uses a heuristic so it isn't reliable for correctness.
llvm-svn: 87047
 | 
| | 
| 
| 
|  | 
llvm-svn: 87042
 | 
| | 
| 
| 
|  | 
llvm-svn: 87040
 | 
| | 
| 
| 
|  | 
llvm-svn: 87036
 | 
| | 
| 
| 
|  | 
llvm-svn: 87035
 | 
| | 
| 
| 
|  | 
llvm-svn: 87034
 | 
| | 
| 
| 
|  | 
llvm-svn: 87030
 | 
| | 
| 
| 
| 
| 
|  | 
This also fixes a build error.
llvm-svn: 87027
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
machine instruction loads or stores from/to a stack slot.  Unlike
isLoadFromStackSlot and isStoreFromStackSlot, the instruction may be
something other than a pure load/store (e.g. it may be an arithmetic
operation with a memory operand).  This helps AsmPrinter determine when
to print a spill/reload comment.
This is only a hint since we may not be able to figure this out in all
cases.  As such, it should not be relied upon for correctness.
Implement for X86.  Return false by default for other architectures.
llvm-svn: 87026
 | 
| | 
| 
| 
|  | 
llvm-svn: 87024
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
and don't assume that the call doesn't throw. It would be nice if there were a
way to determine which is the callee and which is a parameter. In practice, the
architecture we care about normally only have one operand for a call instruction
(x86 and arm).
llvm-svn: 87023
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
slots.  The AsmPrinter will use this information to determine whether to
print a spill/reload comment.
Remove default argument values.  It's too easy to pass a wrong argument
value when multiple arguments have default values.  Make everything
explicit to trap bugs early.
Update all targets to adhere to the new interfaces..
llvm-svn: 87022
 | 
| | 
| 
| 
| 
| 
|  | 
StringsEqualNoCase (from StringExtras.h) to it.
llvm-svn: 87020
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
making it visible to clients and adding LLVM-style cast capability.
This will be used by AsmPrinter to determine when to emit spill comments
for an instruction.
llvm-svn: 87019
 | 
| | 
| 
| 
|  | 
llvm-svn: 87015
 | 
| | 
| 
| 
| 
| 
|  | 
make it permanent and remove old way of inserting intrinsics to encode debug info for line number and scopes.
llvm-svn: 87014
 | 
| | 
| 
| 
| 
| 
| 
|  | 
to directly follow the jump table. Move the layout changes to prior to any
constant island handling.
llvm-svn: 86999
 | 
| | 
| 
| 
|  | 
llvm-svn: 86987
 | 
| | 
| 
| 
| 
| 
|  | 
quite tricky.
llvm-svn: 86986
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
running IPSCCP early, and we run functionattrs interlaced with the inliner,
we often (particularly for small or noop functions) completely propagate
all of the information about a call to its call site in IPSSCP (making a call
dead) and functionattrs is smart enough to realize that the function is
readonly (because it is interlaced with inliner).
To improve compile time and make the inliner threshold more accurate, realize
that we don't have to inline dead readonly function calls.  Instead, just 
delete the call.  This happens all the time for C++ codes, here are some
counters from opt/llvm-ld counting the number of times calls were deleted vs
inlined on various apps:
Tramp3d opt:
  5033 inline                - Number of call sites deleted, not inlined
 24596 inline                - Number of functions inlined
llvm-ld:
  667 inline           - Number of functions deleted because all callers found
  699 inline           - Number of functions inlined
483.xalancbmk opt:
  8096 inline                - Number of call sites deleted, not inlined
 62528 inline                - Number of functions inlined
llvm-ld:
   217 inline           - Number of allocas merged together
  2158 inline           - Number of functions inlined
471.omnetpp:
  331 inline                - Number of call sites deleted, not inlined
 8981 inline                - Number of functions inlined
llvm-ld:
  171 inline           - Number of functions deleted because all callers found
  629 inline           - Number of functions inlined
Deleting a call is much faster than inlining it, and is insensitive to the
size of the callee. :)
llvm-svn: 86975
 |