extractelement operations into a bitcast of the pointer,
then a gep, then a scalar load. Disable this when the vector
only has one element, because it leads to infinite loops in
instcombine (PR4908).
This transformation seems like a really bad idea to me, as it
will likely disable CSE of vector load/stores etc and can be
better done in the code generator when profitable. This
goes all the way back to the first days of packed types,
r25299 specifically.
I'll let those people who care about the performance of vector
code decide what to do with this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81185 91177308-0d34-0410-b5e6-96231b3b80d8
so "Assert1(isa<>); cast<>" is a valid idiom.
Actually check the PHI node's odd-numbered operands for BasicBlock-ness, like
the comment said.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81182 91177308-0d34-0410-b5e6-96231b3b80d8
Make the verifier more robust by avoiding unprotected cast<> calls. Notably,
Assert1(isa<>); cast<> is not safe as Assert1 does not terminate the program.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81179 91177308-0d34-0410-b5e6-96231b3b80d8
from floating-point to integer first, and bitcast the result
back to floating-point. Previously, this test was passing by
falling back to SelectionDAG lowering. The resulting code isn't
as nice, but it's correct and CodeGen now stays on the fast path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81171 91177308-0d34-0410-b5e6-96231b3b80d8
compile-time constant integers or that are out of bounds for their
corresponding static array types. These can cause aliasing that
GlobalOpt assumes won't happen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81165 91177308-0d34-0410-b5e6-96231b3b80d8
an aggregate store overlapping a different aggregate store, despite
the stores having distinct addresses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81164 91177308-0d34-0410-b5e6-96231b3b80d8
is missing the inbounds flag. This is slightly conservative, but it
avoids problems with two constants pointing to the same address but
getting distinct entries in the Memory DenseMap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81163 91177308-0d34-0410-b5e6-96231b3b80d8
when the new method gives the same result as the original
(as far as I can see). This will hopefully pacify icc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81131 91177308-0d34-0410-b5e6-96231b3b80d8
1. DUPMAX is defined in regcomp.c, no need to redefine it in regutils.
2. MSVC doesn't like snprintf, use _snprintf instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81114 91177308-0d34-0410-b5e6-96231b3b80d8
- I think there are more instances of this, but I think they are fixed in Dan's
incoming patch. This one was preventing me from doing a bugpoint reduction
though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81103 91177308-0d34-0410-b5e6-96231b3b80d8
Do not use DenseMap operator[] because it inserts new entry if lookup fails. Use find() to check an entry in a DenseMap first.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81058 91177308-0d34-0410-b5e6-96231b3b80d8
a new class, MachineInstrIndex, which hides arithmetic details from
most clients. This is a step towards allowing the register allocator
to update/insert code during allocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81040 91177308-0d34-0410-b5e6-96231b3b80d8
Constant uniquing tables. This allows distinct ConstantExpr objects
with the same operation and different flags.
Even though a ConstantExpr "a + b" is either always overflowing or
never overflowing (due to being a ConstantExpr), it's still necessary
to be able to represent it both with and without overflow flags at
the same time within the IR, because the safety of the flag may
depend on the context of the use. If the constant really does overflow,
it wouldn't ever be safe to use with the flag set, however the use
may be in code that is never actually executed.
This also makes it possible to merge all the flags tests into a single test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80998 91177308-0d34-0410-b5e6-96231b3b80d8
D test/Analysis/Profiling
--- Reverse-merging r80907 into '.':
U lib/Analysis/ProfileInfoLoaderPass.cpp
Attempt to remove failure in the self-hosting build bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80966 91177308-0d34-0410-b5e6-96231b3b80d8
(i.e., there are no local variables and stuff), we still need to output FDE
information for the pushed registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80960 91177308-0d34-0410-b5e6-96231b3b80d8
and exact flags. Because ConstantExprs are uniqued, creating an
expression with this flag causes all expressions with the same operands
to have the same flag, which may not be safe. Add, sub, mul, and sdiv
ConstantExprs are usually folded anyway, so the main interesting flag
here is inbounds, and the constant folder already knows how to set the
inbounds flag automatically in most cases, so there isn't an urgent need
for the API support.
This can be reconsidered in the future, but for now just removing these
API bits eliminates a source of potential trouble with little downside.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80959 91177308-0d34-0410-b5e6-96231b3b80d8
for the complicated case where one register is tied to multiple destinations.
This avoids the extra scan of instruction operands that was introduced by
my recent change. I also pulled some code out into a separate
TryInstructionTransform method, added more comments, and renamed some
variables.
Besides all those changes, this takes care of a FIXME in the code regarding
an assumption about there being a single tied use of a register when
converting to a 3-address form. I'm not aware of cases where that assumption
is violated, but the code now only attempts to transform an instruction,
either by commuting its operands or by converting to a 3-address form,
for the simple case where there is a single pair of tied operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80945 91177308-0d34-0410-b5e6-96231b3b80d8
- when transforming a vector shift of a non-immediate scalar shift amount, zero
extend the i32 shift amount to i64 since the vector shift reads 64 bits
- when transforming i16 vectors to use a vector shift, zero extend i16 shift amount
- improve the code quality in some cases when transforming vectors to use a vector shift
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80935 91177308-0d34-0410-b5e6-96231b3b80d8
disabling the use of 16-bit operations on x86. This doesn't yet work for
inline asms with 16-bit constraints, vectors with 16-bit elements,
trampoline code, and perhaps other obscurities, but it's enough to try
some experiments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80930 91177308-0d34-0410-b5e6-96231b3b80d8
from MCAsmLexer.h in preparation of supporting other targets. Changed the
X86AsmParser code to reflect this by removing AsmLexer::LexPercent and looking
for AsmToken::Percent when parsing in places that used AsmToken::Register.
Then changed X86ATTAsmParser::ParseRegister to parse out registers as an
AsmToken::Percent followed by an AsmToken::Identifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80929 91177308-0d34-0410-b5e6-96231b3b80d8
that these passes are properly preserved.
Fix several transformation passes that claimed to preserve LoopSimplify
form but weren't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80926 91177308-0d34-0410-b5e6-96231b3b80d8
LoopSimplify form, which is currently only available on Loops (and
not MachineLoops). Also, move the code out of the header file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80923 91177308-0d34-0410-b5e6-96231b3b80d8
instead of a bool argument, and to do the dominator check itself.
This makes it eaiser to use when DominatorTree information is
available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80920 91177308-0d34-0410-b5e6-96231b3b80d8
Removed inverted flag form MaximumSpanningTree, also do not handle so much
information to MaximumSpanningTree.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80911 91177308-0d34-0410-b5e6-96231b3b80d8
different formatting from the old asmprinter, but it should be
semantically the same. We used to get:
popl %eax
addl $_GLOBAL_OFFSET_TABLE_ + [.-.Lllvm$6.$piclabel], %eax
...
Now we get:
popl %eax
.Lpicbaseref6:
addl $(_GLOBAL_OFFSET_TABLE_ + (.Lpicbaseref6 - .Lllvm$6.$piclabel)), %eax
...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80905 91177308-0d34-0410-b5e6-96231b3b80d8
and fix a few things using << on MCSymbols to use ->print(). No
functionality change other than unbreaking my previous patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80890 91177308-0d34-0410-b5e6-96231b3b80d8
simplifylibcalls optimization is thus valid for C++ but not C.
It's not important enough to worry about for C++ apps, so just
remove it.
rdar://7191924
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80887 91177308-0d34-0410-b5e6-96231b3b80d8
avoid reloads by reusing clobbered registers.
This was causing issues in 256.bzip2 when compiled with PIC for
a while (starting at r78217), though the problem has since been masked.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80872 91177308-0d34-0410-b5e6-96231b3b80d8
