llvm.eh.sjlj.* for better clarity as to their purpose and scope. Add
a description of llvm.eh.sjlj.setjmp to ExceptionHandling.html.
(llvm.eh.sjlj.longjmp documentation coming when that implementation is
added).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71758 91177308-0d34-0410-b5e6-96231b3b80d8
Basically, there was a situation where it was getting an empty vector and doing
a .back() on that. Which isn't cool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71746 91177308-0d34-0410-b5e6-96231b3b80d8
block with its unique predecessor. Change the code to assert if that is not
the case, instead of trying to handle situations where the block has
multiple predecessors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71744 91177308-0d34-0410-b5e6-96231b3b80d8
of exception handling builtin sjlj targets in functions turns out not to
be necessary. Marking the intrinsic implementation in the .td file as
defining all registers is sufficient to get the context saved properly by
the containing function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71743 91177308-0d34-0410-b5e6-96231b3b80d8
Dan was trying to catch the case where a basic block ends with a conditional
branch to the fall-through block. In this case, all the instructions have
been moved out of FromBBI, leaving it empty. It cannot end with a
conditional branch. As the existing comment indicates, it will always fall
through to the next block. If the block already had the next block (NBB)
listed as a successor, the preceding loop has a check for that and does not
remove it. Thus, we need to check and add the successor only when it is
not already listed.
With Dan's change, the empty block often ends up with the fall-through
successor listed twice. This exposed the problem in pr4195, where
CodePlacementOpt did not handle the same predecessor listed more than once.
It is also at least partially responsible for pr4202 and probably a similar
issue with Thumb branches being out of range.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71742 91177308-0d34-0410-b5e6-96231b3b80d8
booleans. This gives a better indication of what the "addReg()" is
doing. Remembering what all of those booleans mean isn't easy, especially if you
aren't spending all of your time in that code.
I took Jakob's suggestion and made it illegal to pass in "true" for the
flag. This should hopefully prevent any unintended misuse of this (by reverting
to the old way of using addReg()).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71722 91177308-0d34-0410-b5e6-96231b3b80d8
belonged. The variable declaration stuff wasn't happy with it where it
was. Sorry that the testcase is so big. Bugpoint wasn't able to reduce it
successfully.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71714 91177308-0d34-0410-b5e6-96231b3b80d8
is not known to be nothrow. This allows readnone/readonly functions
to be deleted even if we don't know whether the callee can throw.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71676 91177308-0d34-0410-b5e6-96231b3b80d8
IVUsers.cpp: In member function ‘bool llvm::IVUsers::AddUsersIfInteresting(llvm::Instruction*)’:
IVUsers.cpp:221: warning: ‘isSigned’ may be used uninitialized in this function
with gcc-4.3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71654 91177308-0d34-0410-b5e6-96231b3b80d8
getNoopOrSignExtend, and getTruncateOrNoop. These are similar
to getTruncateOrZeroExtend etc., except that they assert that
the conversion is either not widening or narrowing, as
appropriate. These will be used in some upcoming fixes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71632 91177308-0d34-0410-b5e6-96231b3b80d8
without one. Use it where we were using abs on
int64_t objects.
(I strongly suspect the casts to unsigned in the
fragments in LoopStrengthReduce are not doing whatever
the original intent was, but the obvious change to
uint64_t doesn't work. Maybe later.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71612 91177308-0d34-0410-b5e6-96231b3b80d8
a supporting preliminary patch for GCC-compatible SjLJ exception handling. Note that these intrinsics are not designed to be invoked directly by the user, but
rather used by the front-end as target hooks for exception handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71610 91177308-0d34-0410-b5e6-96231b3b80d8
- moved shrink wrapping code from PrologEpilogInserter.cpp to
new file ShrinkWrapping.cpp.
- moved PEI pass definition into new shared header PEI.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71588 91177308-0d34-0410-b5e6-96231b3b80d8
after finding the (unique) layout predecessor. Sometimes a block may be listed
more than once, and processing it more than once in this loop can lead to
inconsistent values for FtTBB/FtFBB, since the AnalyzeBranch method does not
clear these values. There's no point in continuing the loop regardless.
The testcase for this is reduced from the 2003-05-02-DependentPHI SingleSource
test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71536 91177308-0d34-0410-b5e6-96231b3b80d8
and generalize it so that it can be used by IndVarSimplify. Implement the
base IndVarSimplify transformation code using IVUsers. This removes
TestOrigIVForWrap and associated code, as ScalarEvolution now has enough
builtin overflow detection and folding logic to handle all the same cases,
and more. Run "opt -iv-users -analyze -disable-output" on your favorite
loop for an example of what IVUsers does.
This lets IndVarSimplify eliminate IV casts and compute trip counts in
more cases. Also, this happens to finally fix the remaining testcases
in PR1301.
Now that IndVarSimplify is being more aggressive, it occasionally runs
into the problem where ScalarEvolutionExpander's code for avoiding
duplicate expansions makes it difficult to ensure that all expanded
instructions dominate all the instructions that will use them. As a
temporary measure, IndVarSimplify now uses a FixUsesBeforeDefs function
to fix up instructions inserted by SCEVExpander. Fortunately, this code
is contained, and can be easily removed once a more comprehensive
solution is available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71535 91177308-0d34-0410-b5e6-96231b3b80d8
These values aren't analyzable, so they don't care if more information
about the loop trip count can be had. Also, SCEVUnknown is used for
a PHI while the PHI itself is being analyzed, so it needs to be left
in the Scalars map. This fixes a variety of subtle issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71533 91177308-0d34-0410-b5e6-96231b3b80d8
return the correct value when the cast operand is all zeros. This ought
to be pretty rare, because it would mean that the regular SCEV folding
routines missed a case, though there are cases they might legitimately
miss. Also, it's unlikely anything currently using GetMinTrailingZeros
cares about this case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71532 91177308-0d34-0410-b5e6-96231b3b80d8
Also, if the compare is the only use, LSR would place the iv increment instruction before the compare instead in the latch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71485 91177308-0d34-0410-b5e6-96231b3b80d8
type, rather than assume that it does. If the operand is not vector, it
shouldn't be run through ScalarizeVectorOp. This fixes one of the
testcases in PR3886.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71453 91177308-0d34-0410-b5e6-96231b3b80d8
count down to 0 instead, under very restricted
circumstances. Adjust 4 testcases in which this
optimization fires.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71439 91177308-0d34-0410-b5e6-96231b3b80d8
- reduces _static_ callee saved register spills
and restores similar to Chow's original algorithm.
- iterative implementation with simple heuristic
limits to mitigate compile time impact.
- handles placing spills/restores for multi-entry,
multi-exit regions in the Machine CFG without
splitting edges.
- passes test-suite in LLCBETA mode.
Added contains() method to ADT/SparseBitVector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71438 91177308-0d34-0410-b5e6-96231b3b80d8
only for those. These extern declarations to intrinsics are currently
being emitted at the bottom of generated .s file, which works fine with
gpasm(not sure about MPSAM though).
PIC16 linker generates errors for few cases (function-args/struct_args_5) if you do not include any
extern declarations (even if no intrinsics are being used), but that
needs to be fixed in the linker itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71423 91177308-0d34-0410-b5e6-96231b3b80d8
The DwarfWriter expects DbgScopes and DIEs to behave themselves according to
DwarfWriter's rules. However, inlined functions violate these rules. There are
two different types of DIEs associated with an inlined function: an abstract
instance, which has information about the original source code for the function
being inlined; and concrete instances, which are created for each place the
function was inlined and point back to the abstract instance.
This patch tries to stay true to this schema. It bypasses how regular DbgScopes
and DIEs are created and used when necessary. It provides special handling for
DIEs of abstract and concrete instances.
This doesn't take care of all of the problems with debug info for inlined
functions, but it's a step in the right direction. For one thing, llvm-gcc
generates wrong IR (it's missing some llvm.dbg intrinsics at the point where the
function's inlined) for this example:
#include <stdio.h>
static __inline__ __attribute__((always_inline)) int bar(int x) { return 4; }
void foo() {
long long b = 1;
int Y = bar(4);
printf("%d\n", Y);
}
while clang generates correct IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71410 91177308-0d34-0410-b5e6-96231b3b80d8
None. However, we were always recording the region end. There's no longer a good
reason for this code to be separated out between the different opt levels, as it
was doing pretty much the same thing anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71370 91177308-0d34-0410-b5e6-96231b3b80d8
inlined function or the end of a function. Before, this was never executing the
"inlined" version of the Record method.
This will become important once the inlined Dwarf writer patch lands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71268 91177308-0d34-0410-b5e6-96231b3b80d8
add-recurrence to be exposed. Add a new SCEV folding rule to
help simplify expressions in the presence of these extra truncs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71264 91177308-0d34-0410-b5e6-96231b3b80d8
concrete instance of an inlined function, we can get the actual address of the
abstract instance inside of the compile unit.
This isn't currently used, but will be by a future check-in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71263 91177308-0d34-0410-b5e6-96231b3b80d8
which are not analyzed with SCEV techniques, which can require
brute-forcing through a large number of instructions. This
fixes a massive compile-time issue on 400.perlbench (in
particular, the loop in MD5Transform).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71259 91177308-0d34-0410-b5e6-96231b3b80d8
method, fixing a crash on PR4146. While the store will
ultimately overwrite the "padded size" number of bits in memory,
the stored value may be a subset of this size. This function
only wants to handle the case where all bits are stored.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71224 91177308-0d34-0410-b5e6-96231b3b80d8
scavenger gets confused about register liveness if it doesn't see them.
I'm not thrilled with this solution, but it only comes up when there are dead
copies in the code, which is something that hopefully doesn't happen much.
Here is what happens in pr4100: As shown in the following excerpt from the
debug output of llc, the source of a move gets reloaded from the stack,
inserting a new load instruction before the move. Since that source operand
is a kill, the physical register is free to be reused for the destination
of the move. The move ends up being a no-op, copying R3 to R3, so it is
deleted. But, it leaves behind the load to reload %reg1028 into R3, and
that load is not updated to show that it's destination operand (R3) is dead.
The scavenger gets confused by that load because it thinks that R3 is live.
Starting RegAlloc of: %reg1025<def,dead> = MOVr %reg1028<kill>, 14, %reg0, %reg0
Regs have values:
Reloading %reg1028 into R3
Last use of R3[%reg1028], removing it from live set
Assigning R3 to %reg1025
Register R3 [%reg1025] is never used, removing it from live set
Alternative solutions might be either marking the load as dead, or zapping
the load along with the no-op copy. I couldn't see an easy way to do
either of those, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71196 91177308-0d34-0410-b5e6-96231b3b80d8
bits captured, but the pointer marked nocapture. In fact
I now recall that this problem is why only readnone functions
returning void were considered before! However keep a small
fix that was also in r70876: a readnone function returning
void can result in bits being captured if it unwinds, so
test for this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71168 91177308-0d34-0410-b5e6-96231b3b80d8
checking for bcopy... no
checking for getc_unlocked... Assertion failed: (0 && "Unknown SCEV kind!"), function operator(), file /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/src/lib/Analysis/ScalarEvolution.cpp, line 511.
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/libdecnumber/decUtility.c:360: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[4]: *** [decUtility.o] Error 1
make[4]: *** Waiting for unfinished jobs....
Assertion failed: (0 && "Unknown SCEV kind!"), function operator(), file /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/src/lib/Analysis/ScalarEvolution.cpp, line 511.
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/libdecnumber/decNumber.c:5591: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[4]: *** [decNumber.o] Error 1
make[3]: *** [all-stage2-libdecnumber] Error 2
make[3]: *** Waiting for unfinished jobs....
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71165 91177308-0d34-0410-b5e6-96231b3b80d8
to sorting SCEVs by their kind, sort SCEVs of the same kind according
to their operands. This helps avoid things like (a+b) being a distinct
expression from (b+a).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71160 91177308-0d34-0410-b5e6-96231b3b80d8
array and the add is within range. This helps simplify expressions
expanded by ScalarEvolutionExpander.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71158 91177308-0d34-0410-b5e6-96231b3b80d8
more place. This fixes a bunch of x86-64 JIT regressions.
(Introduced when the value of the magic constant changed
in 68645. At the time apparently nobody noticed; failures
were hidden in 70343-70439 by an unrelated bug, so showed
up again as "new" failures in 70440.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71106 91177308-0d34-0410-b5e6-96231b3b80d8
the readnone. Since MallocInst is scheduled for deletion
it doesn't seem worth doing anything more subtle, such as
having mayWriteToMemory return true for MallocInst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71077 91177308-0d34-0410-b5e6-96231b3b80d8
Split large global data (both initialized and un-initialized) into multiple sections of <= 80 bytes.
Provide routines to manage PIC16 ABI naming conventions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71073 91177308-0d34-0410-b5e6-96231b3b80d8
the optimizers about this. For example, a readonly
function with no uses cannot be removed unless it is
also marked nounwind.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71071 91177308-0d34-0410-b5e6-96231b3b80d8
allow it to have multiple CFG edges to that block. This is needed
to allow MachineBasicBlock::isOnlyReachableByFallthrough to work
correctly. This fixes PR4126.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71018 91177308-0d34-0410-b5e6-96231b3b80d8
- Synchronize instruction length computation code in X86InstrInfo with code in X86CodeEmitter.cpp
Patch by Zoltan Varga.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70929 91177308-0d34-0410-b5e6-96231b3b80d8
CallbackVH, with fixes. allUsesReplacedWith need to
walk the def-use chains and invalidate all users of a
value that is replaced. SCEVs of users need to be
recalcualted even if the new value is equivalent. Also,
make forgetLoopPHIs walk def-use chains, since any
SCEV that depends on a PHI should be recalculated when
more information about that PHI becomes available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70927 91177308-0d34-0410-b5e6-96231b3b80d8
shows up in -print-machineinstrs. This doesn't appear to affect anything, but it was
weird for some DBG_LABELs to have DebugLocs but not all of them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70921 91177308-0d34-0410-b5e6-96231b3b80d8
VirtRegMap keeps track of allocations so it knows what's not used. As a horrible hack, the stack coloring can color spill slots with *free* registers. That is, it replace reload and spills with copies from and to the free register. It unfold instructions that load and store the spill slot and replace them with register using variants.
Not yet enabled. This is part 1. More coming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70787 91177308-0d34-0410-b5e6-96231b3b80d8
makes ScalarEvolution::deleteValueFromRecords, and it's code that
subtly needed to be called before ReplaceAllUsesWith, unnecessary.
It also makes ValueDeletionListener unnecessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70645 91177308-0d34-0410-b5e6-96231b3b80d8
to make the copy constructor and destructor protected, and corresponding
adjustments to the unittests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70644 91177308-0d34-0410-b5e6-96231b3b80d8
of returning a list of pointers to Values that are deleted. This was
unsafe, because the pointers in the list are, by nature of what
RecursivelyDeleteDeadInstructions does, always dangling. Replace this
with a simple callback mechanism. This may eventually be removed if
all clients can reasonably be expected to use CallbackVH.
Use this to factor out the dead-phi-cycle-elimination code from LSR
utility function, and generalize it to use the
RecursivelyDeleteTriviallyDeadInstructions utility function.
This makes LSR more aggressive about eliminating dead PHI cycles;
adjust tests to either be less trivial or to simply expect fewer
instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70636 91177308-0d34-0410-b5e6-96231b3b80d8
it also forget any SCEVs associated with loop-header PHIs in the loop,
as they may be dependent on trip count information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70633 91177308-0d34-0410-b5e6-96231b3b80d8
of LSR. This makes the AddUsersIfInteresting phase of LSR a pure
analysis instead of a phase that potentially does CFG modifications.
The conditions where this code would actually perform a split are
rare, and in the cases where it actually would do a split the split
is usually undone by CodeGenPrepare, and in cases where splits
actually survive into codegen, they appear to hurt more often than
they help.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70625 91177308-0d34-0410-b5e6-96231b3b80d8
target hooks canLosslesslyBitCastTo and isTruncateFree. This allows
targets to avoid worrying about handling all combinations of integer
and pointer types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70555 91177308-0d34-0410-b5e6-96231b3b80d8
artificial "ptrtoint", as it tends to clutter up complicated
expressions. The cast operators now print both source and
destination types, which is usually sufficient.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70554 91177308-0d34-0410-b5e6-96231b3b80d8
classes.
This is implemented as a function rather than a method on TargetRegisterClass
because it is symmetric in its arguments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70512 91177308-0d34-0410-b5e6-96231b3b80d8
compute an upper-bound value for the trip count, in addition to
the actual trip count. Use this to allow getZeroExtendExpr and
getSignExtendExpr to fold casts in more cases.
This may eventually morph into a more general value-range
analysis capability; there are certainly plenty of places where
more complete value-range information would allow more folding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70509 91177308-0d34-0410-b5e6-96231b3b80d8
This is *not* turned on by default. Testing indicates this is just as likely to pessimize code. The main issue seems to be allocation preference doesn't work effectively. That will change once I've taught register allocator "swapping".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70503 91177308-0d34-0410-b5e6-96231b3b80d8
memory operands otherwise the writebacks get lost when the inline asm
doesn't otherwise have side effects. This fixes rdar://6839427, though
clang really shouldn't generate these anymore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70455 91177308-0d34-0410-b5e6-96231b3b80d8
(sext i8 {-128,+,1} to i64) to i64 {-128,+,1}, where the iteration
crosses from negative to positive, but is still safe if the trip
count is within range.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70421 91177308-0d34-0410-b5e6-96231b3b80d8
print sext, zext, and trunc, instead of signextend, zeroextend,
and truncate, respectively, for consistency with the main IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70405 91177308-0d34-0410-b5e6-96231b3b80d8
anything larger than 64-bits, avoiding a crash. This should
really be fixed to use APInts, though type legalization happens
to help us out and we get good code on the attached testcase at
least.
This fixes rdar://6836460
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70360 91177308-0d34-0410-b5e6-96231b3b80d8
an optimization level instead of a simple boolean telling it to generate code
"fast" or the other type of "fast".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70347 91177308-0d34-0410-b5e6-96231b3b80d8
Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want to
use the old behavior, the flag is -O0. This change allows for finer-grained
control over which optimizations are run at different -O levels.
Most of this work was pretty mechanical. The majority of the fixes came from
verifying that a "fast" variable wasn't used anymore. The JIT still uses a
"Fast" flag. I'll change the JIT with a follow-up patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70343 91177308-0d34-0410-b5e6-96231b3b80d8
If the physical register does not belong to the virtual register's regclass,
don't coalesce. The physical register could be an invalid operand for an
instruction using the vreg.
The regclass matching is done after determining the actual subregisters being copied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70298 91177308-0d34-0410-b5e6-96231b3b80d8
Also make the method non-asserting. It will return NULL when given an invalid subreg index.
The method is needed by an upcoming patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70296 91177308-0d34-0410-b5e6-96231b3b80d8
use the old behavior, the flag is -O0. This change allows for finer-grained
control over which optimizations are run at different -O levels.
Most of this work was pretty mechanical. The majority of the fixes came from
verifying that a "fast" variable wasn't used anymore. The JIT still uses a
"Fast" flag. I'm not 100% sure if it's necessary to change it there...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70270 91177308-0d34-0410-b5e6-96231b3b80d8
information to simplify [sz]ext({a,+,b}) to {zext(a),+,[zs]ext(b)},
as appropriate.
These functions and the trip count code each call into the other, so
this requires careful handling to avoid infinite recursion. During
the initial trip count computation, conservative SCEVs are used,
which are subsequently discarded once the trip count is actually
known.
Among other benefits, this change lets LSR automatically eliminate
some unnecessary zext-inreg and sext-inreg operation where the
operand is an induction variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70241 91177308-0d34-0410-b5e6-96231b3b80d8
This should have no effect on generated code, but makes the intermediate state
of the coalescer more sane.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70238 91177308-0d34-0410-b5e6-96231b3b80d8
PR2957
ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.
In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70225 91177308-0d34-0410-b5e6-96231b3b80d8
to precisely describe the h-register subreg register classes.
Thanks to Jakob Stoklund Olesen for spotting this and for the
initial patch!
Also, make getStoreRegOpcode and getLoadRegOpcode aware of the
needs of h registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70211 91177308-0d34-0410-b5e6-96231b3b80d8
another stub, but then never calling the jitted function) can cause the JIT to
leave a stub in place. Judging by the comments this is a known deficiency, so
we're just not going to use AssertingVH for the StubToFunctionTy map.
Also shorten some lines longer than 80 columns.
This fixes the "make check" failure with ocaml on x86-64 linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70185 91177308-0d34-0410-b5e6-96231b3b80d8
the trunc is directly replaced with the smaller load, so don't
try to create a new sext node. This fixes PR4050.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70179 91177308-0d34-0410-b5e6-96231b3b80d8