| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
InstructionSimplify.cpp. Other fixups as needed.
Part of rdar://10500969
llvm-svn: 145559
|
|
|
|
| |
llvm-svn: 145420
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weak variable are compiled by different compilers, such as GCC and LLVM, while
LLVM may increase the alignment to the preferred alignment there is no reason to
think that GCC will use anything more than the ABI alignment. Since it is the
GCC version that might end up in the final program (as the linkage is weak), it
is wrong to increase the alignment of loads from the global up to the preferred
alignment as the alignment might only be the ABI alignment.
Increasing alignment up to the ABI alignment might be OK, but I'm not totally
convinced that it is. It seems better to just leave the alignment of weak
globals alone.
llvm-svn: 145413
|
|
|
|
|
|
|
|
| |
Suggested in code review by Eli.
That code in InstCombine looks kinda suspicious.
llvm-svn: 145013
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The right way to check for a binary operation is
cast<BinaryOperator>. The original check: cast<Instruction> &&
numOperands() == 2 would match phi "instructions", leading to an
infinite loop in extreme corner case: a useless phi with operands
[self, constant] that prior optimization passes failed to remove,
being used in the loop by another useless phi, in turn being used by an
lshr or udiv.
Fixes PR11350: runaway iteration assertion.
llvm-svn: 144935
|
|
|
|
|
|
|
|
|
|
| |
Add a custom name for fwrite and fputs on x86-32 OSX. Make SimplifyLibCalls honor the custom
names for fwrite and fputs.
Fixes <rdar://problem/9815881>.
llvm-svn: 144876
|
|
|
|
| |
llvm-svn: 144748
|
|
|
|
| |
llvm-svn: 144675
|
|
|
|
| |
llvm-svn: 144536
|
|
|
|
| |
llvm-svn: 144416
|
|
|
|
|
|
| |
<rdar://problem/10405911>
llvm-svn: 144000
|
|
|
|
| |
llvm-svn: 143634
|
|
|
|
|
|
| |
Patch by Kostya Serebryany.
llvm-svn: 143405
|
|
|
|
|
|
|
|
|
|
| |
instructions.
This doesn't introduce any optimizations we weren't doing before (except
potentially due to pass ordering issues), now passes will eliminate them sooner
as part of their own cleanups.
llvm-svn: 142787
|
|
|
|
| |
llvm-svn: 142684
|
|
|
|
|
|
| |
definition is unused, and enhance it so it can tell that functions which are only used by a blockaddress are in fact dead. This probably doesn't happen much on most code, but the Linux kernel's _THIS_IP_ can trigger this issue with blockaddress. (GlobalDCE can also handle the given tescase, but we only run that at -O3.) Found while looking at PR11180.
llvm-svn: 142572
|
|
|
|
| |
llvm-svn: 142162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
promoting allocas to preferred alignments that exceed the natural
alignment. This avoids some potentially expensive dynamic stack realignments.
The natural stack alignment is set in target data strings via the "S<size>"
option. Size is in bits and must be a multiple of 8. The natural stack alignment
defaults to "unspecified" (represented by a zero value), and the "unspecified"
value does not prevent any alignment promotions. Target maintainers that care
about avoiding promotions should explicitly add the "S<size>" option to their
target data strings.
llvm-svn: 141599
|
|
|
|
|
|
|
|
| |
This handles the case in which LSR rewrites an IV user that is a phi and
splits critical edges originating from a switch.
Fixes <rdar://problem/6453893> LSR is not splitting edges "nicely"
llvm-svn: 141059
|
|
|
|
| |
llvm-svn: 141058
|
|
|
|
|
|
| |
but not load instructions. Noticed by inspection.
llvm-svn: 140966
|
|
|
|
|
|
| |
operand ordering. Patch by Stepan Dyatkovskiy.
llvm-svn: 140803
|
|
|
|
|
|
|
|
| |
to be uniqued, without any benefit.
If someone prefers %tmp42 to %42, run instnamer.
llvm-svn: 140634
|
|
|
|
|
|
|
| |
Some passes require breaking critical edges before they're called. Don't
segfault because of that.
llvm-svn: 140196
|
|
|
|
| |
llvm-svn: 140172
|
|
|
|
|
|
| |
blocks to extract.
llvm-svn: 140168
|
|
|
|
| |
llvm-svn: 140164
|
|
|
|
| |
llvm-svn: 140094
|
|
|
|
|
|
|
|
|
|
| |
extract the landing pad block. Otherwise, there will be a situation where the
invoke's unwind edge lands on a non-landing pad.
We also forbid the user from extracting the landing pad block by itself. Again,
this is not a valid transformation.
llvm-svn: 140083
|
|
|
|
| |
llvm-svn: 140026
|
|
|
|
|
|
| |
exception.
llvm-svn: 139117
|
|
|
|
|
|
|
|
| |
- Reword comments.
- Allow undefined behavior interfering with undefined behavior.
- Add address space checks.
llvm-svn: 138619
|
|
|
|
|
|
|
|
|
|
| |
or store to the address returned by the PHI node then we can consider this incoming value as dead and remove the edge pointing there, unless there are instructions that can affect control flow executed in between.
In theory this could be extended to other instructions, eg. division by zero, but it's likely that it will "miscompile" some code because people depend on div by zero not trapping. NULL pointer dereference usually leads to a crash so we should be on the safe side.
This shrinks the size of a Release clang by 16k on x86_64.
llvm-svn: 138618
|
|
|
|
|
|
| |
getFirstNonPHI so that it will skip over the landingpad instructions as well.
llvm-svn: 138537
|
|
|
|
|
|
|
|
| |
dominator information even though dominators were previously computed.
Patch by Nick Sumner.
llvm-svn: 138449
|
|
|
|
|
|
| |
then don't split it a second time, since that block will be dead.
llvm-svn: 138153
|
|
|
|
|
|
|
|
|
|
| |
We have to be careful when splitting the landing pad block, because the
landingpad instruction is required to remain as the first non-PHI of an invoke's
unwind edge. To retain this, we split the block into two blocks, moving the
predecessors within the loop to one block and the remaining predecessors to the
other. The landingpad instruction is cloned into the new blocks.
llvm-svn: 138015
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SplitLandingPadPredecessors is similar to SplitBlockPredecessors in that it
splits the current block and attaches a set of predecessors to the new basic
block. However, it differs from SplitBlockPredecessors in that it's specifically
designed to handle landing pad blocks.
Two new basic blocks are created: one that is has the vector of predecessors as
its predecessors and one that has the remaining predecessors as its
predecessors. Those two new blocks then receive a cloned copy of the landingpad
instruction from the original block. The landingpad instructions are joined in a
PHI, etc. Like SplitBlockPredecessors, it updates the LLVM IR, AliasAnalysis,
DominatorTree, DominanceFrontier, LoopInfo, and LCCSA analyses.
llvm-svn: 138014
|
|
|
|
|
|
| |
aren't from an indirect branch need to be dominated by the loop header.
llvm-svn: 137981
|
|
|
|
|
|
| |
function.
llvm-svn: 137979
|
|
|
|
| |
llvm-svn: 137978
|
|
|
|
| |
llvm-svn: 137959
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 137926
|
|
|
|
| |
llvm-svn: 137872
|
|
|
|
|
|
|
|
| |
One way to exit the loop is through an unwind edge. However, that may involve
splitting the critical edge of the landing pad, which is non-trivial. Prevent
the transformation from rewriting the landing pad exit loop block.
llvm-svn: 137871
|
|
|
|
|
|
| |
so requires more care than this generic algorithm should handle.
llvm-svn: 137866
|
|
|
|
| |
llvm-svn: 137743
|
|
|
|
|
|
| |
to be wrong (or at least somewhat suspect). Leave a FIXME for Bill.
llvm-svn: 137694
|
|
|
|
| |
llvm-svn: 137693
|
|
|
|
|
|
|
|
| |
This commit includes a mention of the landingpad instruction, but it's not
changing the behavior around it. I think the current behavior is correct,
though. Bill, can you double-check that?
llvm-svn: 137691
|