add sldt GR32, which isn't documented in the intel manual
but which gas accepts. Part of rdar://8418316
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113938 91177308-0d34-0410-b5e6-96231b3b80d8
version because it adds a prefix and makes even less sense
than the other broken forms. This wraps up rdar://8431422
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113932 91177308-0d34-0410-b5e6-96231b3b80d8
"The register specified for a dregpair is the corresponding Q register, so to
get the pair, we need to look up the sub-regs based on the qreg. Create a
lookup function since we don't have access to TargetRegisterInfo here to
be able to use getSubReg(ARM::dsub_[01])."
Additionaly, fix the NEON VLD1* and VST1* instruction patterns not to use
the dregpair modifier for the 2xdreg versions. Explicitly specifying the two
registers as operands is more correct and more consistent with the other
instruction patterns. This enables further cleanup of special case code in the
disassembler as a nice side-effect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113903 91177308-0d34-0410-b5e6-96231b3b80d8
deleted. Fix this by doing the copyValue's before we delete stuff!
The testcase only repros the problem on my system with valgrind.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113820 91177308-0d34-0410-b5e6-96231b3b80d8
to expose greater opportunities for store narrowing in codegen. This patch fixes a potential
infinite loop in instcombine caused by one of the introduced transforms being overly aggressive.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113763 91177308-0d34-0410-b5e6-96231b3b80d8
This can result in increased opportunities for store narrowing in code generation. Update a number of
tests for this change. This fixes <rdar://problem/8285027>.
Additionally, because this inverts the order of ors and ands, some patterns for optimizing or-of-and-of-or
no longer fire in instances where they did originally. Add a simple transform which recaptures most of these
opportunities: if we have an or-of-constant-or and have failed to fold away the inner or, commute the order
of the two ors, to give the non-constant or a chance for simplification instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113679 91177308-0d34-0410-b5e6-96231b3b80d8
to use AddrMode4, there was a count of the registers stored in one of the
operands. I changed that to just count the operands but forgot to adjust for
the size of D registers. This was noticed by Evan as a performance problem
but it is a potential correctness bug as well, since it is possible that this
could merge a base update with a non-matching immediate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113576 91177308-0d34-0410-b5e6-96231b3b80d8
take multiple cycles to decode.
For the current if-converter clients (actually only ARM), the instructions that
are predicated on false are not nops. They would still take machine cycles to
decode. Micro-coded instructions such as LDM / STM can potentially take multiple
cycles to decode. If-converter should take treat them as non-micro-coded
simple instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113570 91177308-0d34-0410-b5e6-96231b3b80d8
- This is annoying, because we have to scatter this check everywhere that could emit real data, but I see no better solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113552 91177308-0d34-0410-b5e6-96231b3b80d8
- Output format and some of the code stolen from macho-dump.
- Somewhat incomplete and probably buggy.
- Comes with a very basic test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113488 91177308-0d34-0410-b5e6-96231b3b80d8
of checking for either 4 or 8 is not very satisfactory, but
it would catch the original problem (an alignment of 1).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113485 91177308-0d34-0410-b5e6-96231b3b80d8
removed. Not that the XTARGET wasn't doing anything since it
does nothing without an accompanying XFAIL.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113484 91177308-0d34-0410-b5e6-96231b3b80d8
the VST pseudos. The VLD/VST scheduling still needs work (see pr6722), but
at least we shouldn't confuse the loads with the stores.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113473 91177308-0d34-0410-b5e6-96231b3b80d8
unrolling threshold to the optimize-for-size threshold. Basically, for loops containing calls, unrolling
can still be profitable as long as the loop is REALLY small.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113439 91177308-0d34-0410-b5e6-96231b3b80d8
