Patch replaces old isEquivalentGEP implementation, and changes type of
comparison result from bool (equal or not) to {-1, 0, 1} (less, equal, greater).
This patch belongs to patch series that improves MergeFunctions
performance time from O(N*N) to O(N*log(N)).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208976 91177308-0d34-0410-b5e6-96231b3b80d8
Patch replaces old isEquivalentOperation implementation, and changes type of
comparison result from bool (equal or not) to {-1, 0, 1} (less, equal, greater).
This patch belongs to patch series that improves MergeFunctions
performance time from O(N*N) to O(N*log(N)).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208973 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen has a fairly dubious heuristic to decide whether an alias should be
printed: does the alias have lest operands than the real instruction. This is
bad enough (particularly with no way to override it), but it should at least be
calculated consistently for both strings.
This patch implements that logic: first get the *correct* string for the
variant, in the same way as the Matcher, without guessing; then count the
number of whitespace chars.
There are basically 4 changes this brings about after the previous
commits; all of these appear to be good, so I have changed the tests:
+ ARM64: we print "neg X, Y" instead of "sub X, xzr, Y".
+ ARM64: we skip implicit "uxtx" and "uxtw" modifiers.
+ Sparc: we print "mov A, B" instead of "or %g0, A, B".
+ Sparc: we print "fcmpX A, B" instead of "fcmpX %fcc0, A, B"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208969 91177308-0d34-0410-b5e6-96231b3b80d8
The canonical syntax is "fcmXY ..., #0.0".
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208968 91177308-0d34-0410-b5e6-96231b3b80d8
This alias appears not to have an appropriate PrintMethod. Normally, I'd look
into it, but since AArch64 is disappearing soon it's probably not worth it.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208967 91177308-0d34-0410-b5e6-96231b3b80d8
These aliases are handled entirely in C++ and only having TableGen InstAliases
for some of them was confusing LLVM.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208966 91177308-0d34-0410-b5e6-96231b3b80d8
Certainly not without having a custom PrintMethod to invert the immediate
beforehand. But probably not at all.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208964 91177308-0d34-0410-b5e6-96231b3b80d8
In AT&T syntax, we should probably print the full "movl" or "movw". TableGen
used to ignore these aliases because it was miscounting the number of operands.
This fixes the issue.
This will be tested when the TableGen "should I print this Alias"
heuristic is fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208963 91177308-0d34-0410-b5e6-96231b3b80d8
Actually, MOV sometimes is canonical, but for now this is a better
approximation than what's there.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208962 91177308-0d34-0410-b5e6-96231b3b80d8
You can perform (say) an fcmle operation by swapping the operands on an fcmge,
but it shouldn't be printed like that.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208961 91177308-0d34-0410-b5e6-96231b3b80d8
We accept "ldr w3, [x1, #-1]" as a convenience, but we should still print the
canonical "ldur" form.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208960 91177308-0d34-0410-b5e6-96231b3b80d8
If an ANDS instruction has Rd == ZR it should be printed as TST since
its only effect is on the flags register NZCV.
This will be tested when the TableGen "should I print this Alias"
heuristic is fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208959 91177308-0d34-0410-b5e6-96231b3b80d8
MOV is almost always the right thing to print if possile. People understand it.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208958 91177308-0d34-0410-b5e6-96231b3b80d8
For example, the full instruction "sub w0, wzr, w1, uxtw" could print as either
"neg w0, w1" or "sub w0, wzr, w1". The former is better.
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208957 91177308-0d34-0410-b5e6-96231b3b80d8
You can write "lslv w0, w1, w2" (probably for legacy reasons), but it should be
printed as simply "lsl".
This will be tested when the TableGen "should I print this Alias" heuristic is
fixed (very soon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208956 91177308-0d34-0410-b5e6-96231b3b80d8
This patch belongs to patch series that improves MergeFunctions
performance time from O(N*N) to O(N*log(N)).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208953 91177308-0d34-0410-b5e6-96231b3b80d8
Add some Windows on ARM specific library calls. These are provided by msvcrt,
and can be used to perform integer to floating-point conversions (and
vice-versa) mirroring similar functions in the RTABI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208949 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes a LLVM compilation may take more time then a client would like to
wait for. The problem is that it is not possible to safely suspend the LLVM
thread from the outside. When the timing is bad it might be possible that the
LLVM thread holds a global mutex and this would block any progress in any other
thread.
This commit adds a new yield callback function that can be registered with a
context. LLVM will try to yield by calling this callback function, but there is
no guaranteed frequency. LLVM will only do so if it can guarantee that
suspending the thread won't block any forward progress in other LLVM contexts
in the same process.
Once the client receives the call back it can suspend the thread safely and
resume it at another time.
Related to <rdar://problem/16728690>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208945 91177308-0d34-0410-b5e6-96231b3b80d8
Allow multiple raw profiles to coexist in a single .profraw file,
given the following conditions:
- Zero padding at the end of or between profiles will be skipped.
- Each profile must start with a valid header.
- Mixing endianness or pointer sizes in concatenated profiles files is
not allowed.
This is needed to handle cases where a program's shared libraries are
profiled as well as the main executable itself, as we'll need to emit
each executable's counters. Combining the tables in the runtime would
be expensive for the instrumented program.
rdar://16918688
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208938 91177308-0d34-0410-b5e6-96231b3b80d8
Previously this would fail with an assertion failure when trying to add
an alignment attribute without a value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208935 91177308-0d34-0410-b5e6-96231b3b80d8
This commit implements two command line switches -global-merge-on-external
and -global-merge-aligned, and both of them are false by default, so this
optimization is disabled by default for all targets.
For ARM64, some back-end behaviors need to be tuned to get this optimization
further enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208934 91177308-0d34-0410-b5e6-96231b3b80d8
Since type units in the dwo file are handled by a debug aware tool, they
don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208930 91177308-0d34-0410-b5e6-96231b3b80d8
It is more appropriate than the current situation, when one flag
(AbsoluteFilePath) is relevant only if another flag is set.
This refactoring would also simplify fetching the short function name
(stored in DW_AT_name) instead of a linkage name returned currently.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208921 91177308-0d34-0410-b5e6-96231b3b80d8
We have to iterate over all the calls that were inlined to find out if
any were musttail.
Sink another variable down to where its used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208913 91177308-0d34-0410-b5e6-96231b3b80d8
The interesting case is what happens when you inline a musttail call
through a musttail call site. In this case, we can't break perfect
forwarding or allow any stack growth.
Instead of merging control flow from the inlined return instruction
after a musttail call into the body of the caller, leave the inlined
return instruction in the caller so that the musttail call stays in the
tail position.
More work is required in http://reviews.llvm.org/D3630 to handle the
case where the inlined function has dynamic allocas or byval arguments.
Reviewers: chandlerc
Differential Revision: http://reviews.llvm.org/D3491
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208910 91177308-0d34-0410-b5e6-96231b3b80d8
Added target specific combine rules to fold blend intrinsics according
to the following rules:
1) fold(blend A, A, Mask) -> A;
2) fold(blend A, B, <allZeros>) -> A;
3) fold(blend A, B, <allOnes>) -> B.
Added two new tests to verify that the new folding rules work for all
the optimized blend intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208895 91177308-0d34-0410-b5e6-96231b3b80d8
We now use SReg_* for integer types and VReg_* for floating-point types.
This should help simplify the SIFixSGPRCopies pass and no longer causes
ISel to insert a COPY after termiator instuctions that output a value.
This change is covered by exisitng tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208888 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, TableGen assumed that every aliased operand consumed precisely 1
MachineInstr slot (this was reasonable because until a couple of days ago,
nothing more complicated was eligible for printing).
This allows a couple more ARM64 aliases to print so we can remove the special
code.
On the X86 side, I've gone for explicit AT&T size specifiers as the default, so
turned off a few of the aliases that would have just started printing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208880 91177308-0d34-0410-b5e6-96231b3b80d8
In all cases, if a "mov" alias exists, it is the canonical form of the
instruction. Now that TableGen can support aliases containing syntax variants,
we can enable them and improve the quality of the asm output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208874 91177308-0d34-0410-b5e6-96231b3b80d8
To get at least one use of the change (and some actual tests) in with its
commit, I've enabled the AArch64 & ARM64 NEON mov aliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208867 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we ignored the difference between V64 and V128 when parsing
assembly: they both got mapped to registers in the FPR128 class. This is
basically harmless at the moment because they both print and encode the same
way. However, it will affect the printing of aliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208866 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
No support for symbols in place of the immediate yet since it requires new
relocations.
Depends on D3671
Reviewers: jkolek, zoran.jovanovic, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3689
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208858 91177308-0d34-0410-b5e6-96231b3b80d8
much more effectively when trying to constant fold a load of a constant.
Previously, we only handled bitcasts by trying to find a totally generic
byte representation of the constant and use that. Now, we look through
the bitcast to see what constant we might fold the load into, and then
try to form a constant expression cast of the found value that would be
equivalent to loading the value.
You might wonder why on earth this actually matters. Well, turns out
that the Itanium ABI causes us to create a single array for a vtable
where the first elements are virtual base offsets, followed by the
virtual function pointers. Because the array is homogenous the element
type is consistently i8* and we inttoptr the virtual base offsets into
the initial elements.
Then constructors bitcast these pointers to i64 pointers prior to
loading them. Boom, no more constant folding of virtual base offsets.
This is the first fix to LLVM to address the *insane* performance Eric
Niebler discovered with Clang on his range comprehensions[1]. There is
more to come though, this doesn't *really* fix the problem fully.
[1]: http://ericniebler.com/2014/04/27/range-comprehensions/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208856 91177308-0d34-0410-b5e6-96231b3b80d8
if ((x & C) == 0) x |= C becomes x |= C
if ((x & C) != 0) x ^= C becomes x &= ~C
if ((x & C) == 0) x ^= C becomes x |= C
if ((x & C) != 0) x &= ~C becomes x &= ~C
if ((x & C) == 0) x &= ~C becomes nothing
Z3 Verifications code for above transform
http://rise4fun.com/Z3/Pmsh
Differential Revision: http://reviews.llvm.org/D3717
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208848 91177308-0d34-0410-b5e6-96231b3b80d8
Abstract variables should never have/use locations. In this case the
data wasn't used, so no functional change intended here, just
simplification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208820 91177308-0d34-0410-b5e6-96231b3b80d8
Many old tests using prior schemas still had some brokenness here (both
indirect arrays and arrays with single bogus elements). Fixed those up
so they don't hit the new assertions.
Also reduced nesting in some places, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208817 91177308-0d34-0410-b5e6-96231b3b80d8
This is just unneccessary - we only create abstract definitions when
we're inlining anyway, so there's no reason to delay this to see if
we're going to inline anything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208798 91177308-0d34-0410-b5e6-96231b3b80d8
If the function has the landingpad instruction, then the
handlerdata should be emitted even if the function has
nouwnind attribute. Otherwise, following code will not
work:
void test1() noexcept {
try {
throw_exception();
} catch (...) {
log_unexpected_exception();
}
}
Since the cantunwind was incorrectly emitted and the
LSDA is not available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208791 91177308-0d34-0410-b5e6-96231b3b80d8
For example
tzcntl %edi, %ebx
testl %edi, %edi
je .label
can be rewritten into
tzcntl %edi, %ebx
jb .label
A minor complication is that tzcnt sets CF instead of ZF when the input
is zero, we have to rewrite users of the flags from ZF to CF. Currently
we recognize patterns using lzcnt, tzcnt and popcnt.
Differential Revision: http://reviews.llvm.org/D3454
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208788 91177308-0d34-0410-b5e6-96231b3b80d8
Most importantly, it gives debug location info to the coverage callback.
This change also removes 2 cases of unnecessary setDebugLoc when IRBuilder
is created with the same debug location.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208767 91177308-0d34-0410-b5e6-96231b3b80d8
The ELF header e_flags field in the MIPS related test cases handled
incorrectly. The obj2yaml prints too many flags. I will fix that in the
next patches.
The patch reviewed by Michael Spencer and Sean Silva.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208752 91177308-0d34-0410-b5e6-96231b3b80d8
The UDF instruction is a reserved undefined instruction space. The assembler
mnemonic was introduced with ARM ARM rev C.a. The instruction is not predicated
and the immediate constant is ignored by the CPU. Add support for the three
encodings for this instruction.
The changes to the invalid instruction test is due to the fact that the invalid
instructions actually overlap with the undefined instruction. Introduction of
the new instruction results in a partial decode as an undefined sequence. Drop
the tests as they are invalid instruction patterns anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208751 91177308-0d34-0410-b5e6-96231b3b80d8
This was reverted in r208642 due to regressions surrounding file changes
within lexical scopes causing inlining information to be lost.
The issue was in LexicalScopes::getOrCreateInlinedScope, where I was
previously testing "isLexicalBlock" which is false for
"DILexicalBlockFile" (a scope used to represent changes in the current
file name) and assuming it was then a function (breaking out of the
inlined scope path and reaching for the parent non-inlined scopes). By
inverting the condition and testing for "isSubprogram" the correct
behavior is attained.
(also found some weirdness in Clang, see r208742 when reducing this test
case - the resulting test case doesn't apply with the Clang fix, but
I've added a more realistic test case to inline-scopes.ll which does
reproduce the issue and demonstrate the fix)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208748 91177308-0d34-0410-b5e6-96231b3b80d8
Iterating over a DenseMaop is non-deterministic and results to unpredictable IR
output.
Based on a patch by Daniel Reynaud!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208728 91177308-0d34-0410-b5e6-96231b3b80d8
member variable and sink the initialization of crbits into the
subtarget feature reset code.
No functional change, but this refactor will be used in a future
commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208726 91177308-0d34-0410-b5e6-96231b3b80d8
This allows code to statically accept a Function or a GlobalVariable, but
not an alias. This is already a cleanup by itself IMHO, but the main
reason for it is that it gives a lot more confidence that the refactoring to fix
the design of GlobalAlias is correct. That will be a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208716 91177308-0d34-0410-b5e6-96231b3b80d8
This commit was already commited as revision rL208689 and discussd in
phabricator revision D3704.
But the test file was crashing on OS X and windows.
I fixed the test file in the same way as in rL208340.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208711 91177308-0d34-0410-b5e6-96231b3b80d8
compared to 'AddrMode.BaseReg'. In the case that 'AddrMode.BaseReg' is
nullptr, 'Result' will also be nullptr, so the cast causes an assertion. We
should use dyn_cast_or_null here to check 'Result' is not null and it is an
instruction.
Bug found by Mats Petersson, and I reduced his IR to get a test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208705 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-3 that was available in MIPS32R2.
To limit the number of tests required, only one 32-bit and one 64-bit ISA
prior to MIPS32/MIPS64 are tested.
rdhwr has been deliberately left without an ISA annotation for now. This is
because the assembler and CodeGen disagree on when the instruction is
available. Strictly speaking, it is only available in MIPS32r2 and
MIPS64r2. However, it is emulated by a kernel trap on earlier ISA's and is
necessary for TLS so CodeGen should emit it on older ISA's too.
Depends on D3696
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3697
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208690 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We are currently very close to the 32-bit limit of the current assembler
implementation. This is because there is no way to represent an instruction
that is available in, for example, Mips3 or Mips32. We have to define a
feature bit that represents this.
This patch cleans up a pair of redundant feature bits and slightly postpones the
point we will reach the limit.
Reviewers: zoran.jovanovic, jkolek, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3703
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208685 91177308-0d34-0410-b5e6-96231b3b80d8
We already had an assert for foo->RAUW(foo), but not for something like
foo->RAUW(GEP(foo)) and would go in an infinite loop trying to apply
the replacement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208663 91177308-0d34-0410-b5e6-96231b3b80d8
Normally, patterns like (add x, (setcc cc ...)) will be folded into
(csel x, x+1, not cc). However, if there is a ZEXT after SETCC, they
won't be folded. This patch recognizes the ZEXT and allows the
generation of CSINC.
This patch fixes bug 19680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208660 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r208506.
Some inlined subroutine scopes appear to be missing with this change.
Reverting while I investigate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208642 91177308-0d34-0410-b5e6-96231b3b80d8
The problem occurs when a non-i1 setcc is inverted. For example 'i8 = setcc' will get 'xor 0xff' to invert this. This is clearly wrong when the boolean contents are ZeroOrOne.
This patch introduces getLogicalNOT and updates SetCC legalisation to use it.
Reviewed by Hal Finkel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208641 91177308-0d34-0410-b5e6-96231b3b80d8
Right now the load may not get DCE'd because of the side-effect of updating
the base pointer.
This can happen if we lower a read-modify-write of an illegal larger type
(e.g. i48) such that the modification only affects one of the subparts (the
lower i32 part but not the higher i16 part). See the testcase.
In order to spot the dead load we need to revisit it when SimplifyDemandedBits
decided that the value of the load is masked off. This is the
CommitTargetLoweringOpt piece.
I checked compile time with ARM64 by sending SPEC bitcode files through llc.
No measurable change.
Fixes <rdar://problem/16031651>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208640 91177308-0d34-0410-b5e6-96231b3b80d8
r208453 added support for having sret on the second parameter. In that
change, the code for copying sret into a virtual register was hoisted
into the loop that lowers formal parameters. This caused a "Wrong
topological sorting" assertion failure during scheduling when a
parameter is passed in memory. This change undoes that by creating a
second loop that deals with sret.
I'm worried that this fix is incomplete. I don't fully understand the
dependence issues. However, with this change we produce the same DAGs
we used to produce, so if they are broken, they are just as broken as
they have always been.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208637 91177308-0d34-0410-b5e6-96231b3b80d8
SECTDIFF relocations on 32-bit x86.
This fixes several of the MCJIT regression test failures that show up on 32-bit
builds.
<rdar://problem/16886294>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208635 91177308-0d34-0410-b5e6-96231b3b80d8
The current patterns for REV16 misses mostn __builtin_bswap16() due to
legalization promoting the operands to from load/stores toi32s and then
truncing/extending them. This patch adds new patterns that catch the resultant
DAGs and codegens them to rev16 instructions. Tests included.
rdar://15353652
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208620 91177308-0d34-0410-b5e6-96231b3b80d8
One test case had to be updated as it still had the extra indirection
for the variable list - removing the extra indirection got it back to
passing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208608 91177308-0d34-0410-b5e6-96231b3b80d8
This is a slightly different approach to AArch64 (the base instruction
definitions aren't quite right for that to work), but achieves the
same thing and reduces C++ hackery in AsmParser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208605 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The 'mul' line of the test is temporarily commented out because it currently matches the MIPS32 mul instead of the MIPS32r6 mul. This line will be uncommented when we disable the MIPS32 mul on MIPS32r6.
Reviewers: jkolek, zoran.jovanovic, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3668
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208576 91177308-0d34-0410-b5e6-96231b3b80d8
If this code triggers, any immediate has already been validated so it can't
possibly trigger a diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208564 91177308-0d34-0410-b5e6-96231b3b80d8
