instruction based on the t_addrmode_s# mode and what it returned. There is some
obvious badness to this. In particular, it's hard to do MC-encoding when the
instruction may change out from underneath you after the t_addrmode_s# variable
is finally resolved.
The solution is to revert a long-ago change that merged the reg/reg and reg/imm
versions. There is the addition of several new addressing modes. They no longer
have extraneous operands associated with them. I.e., if it's reg/reg we don't
have to have a dummy zero immediate tacked on to the SDNode.
There are some obvious cleanups here, which will happen shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121747 91177308-0d34-0410-b5e6-96231b3b80d8
Use the same COPY_TO_REGCLASS approach as for the 2-register *_sfp instructions.
This change made a big difference in the code generated for the
CodeGen/Thumb2/cross-rc-coalescing-2.ll test: The coalescer is still doing
a fine job, but some instructions that were previously moved outside the loop
are not moved now. It's using fewer VFP registers now, which is generally
a good thing, so I think the estimates for register pressure changed and that
affected the LICM behavior. Since that isn't obviously wrong, I've just
changed the test file. This completes the work for Radar 8711675.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121730 91177308-0d34-0410-b5e6-96231b3b80d8
as a "long" direct branch. While the mnemonics are the same, they encode the branch offset differently, and
the Darwin assembler appears to prefer the "long" form for direct branches. Thus, in the name of bitwise
equivalence, provide encoding and fixup support for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121710 91177308-0d34-0410-b5e6-96231b3b80d8
class A<bit a, bits<3> x, bits<3> y> {
bits<3> z;
let z = !if(a, x, y);
}
The variable z will get the value of x when 'a' is 1 and 'y' when a is '0'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121666 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the previous header. I don't think we need to expose to end users
that we use TableGen to produce our version of arm_neon.h, and that header
was also using doubleslash comments which could be a problem when using it
in strict C89 compilations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121390 91177308-0d34-0410-b5e6-96231b3b80d8
particular, the immediate has 20-bits of value instead of 21. And bit 0 is '0'
always. Going through the BL fixup encoding was trashing the "bit 0 is '0'"
invariant.
Attempt to get the encoding at slightly more correct with this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121336 91177308-0d34-0410-b5e6-96231b3b80d8
An OpReinterpret entry is handled by translating it to OpCast intrinsics for
all combinations of source and destination types with the same total size.
This will be used to generate all the vreinterpret intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121087 91177308-0d34-0410-b5e6-96231b3b80d8
Intrinsics implemented with Clang builtins could already be implemented as
either inline functions or macros, but intrinsics implemented directly
(without builtins) could only be inline functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120763 91177308-0d34-0410-b5e6-96231b3b80d8
For most intrinsics, there is no need to allocate a temporary to hold the
result value; just return it directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120695 91177308-0d34-0410-b5e6-96231b3b80d8
Since we're casting them for the calls to the builtins, we need this to
make sure their types get checked in the same way they would if the intrinsics
were implemented as inline functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120693 91177308-0d34-0410-b5e6-96231b3b80d8
This is in preparation for adding assignments to temporaries to ensure
that the proper type checking is done.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120649 91177308-0d34-0410-b5e6-96231b3b80d8
