| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Discovered by running fp-move-05.ll with -verify-machineinstrs (added
to test case run).
llvm-svn: 251298
|
|
|
|
|
|
|
| |
Discovered by running fp-cmp-02.ll with -verify-machineinstrs (now added
to test run).
llvm-svn: 251297
|
|
|
|
|
|
|
|
| |
Discovered by testing fp-add-02.ll with -verify-machineinstrs.
Test case updated to always run with -verify-machineinstrs.
llvm-svn: 251296
|
|
|
|
|
|
|
|
| |
Instead of XFAIL-ing the tests with the wrong usage of the "interrupt"
attribute, we should check that we emit the correct error messages to
the user.
llvm-svn: 251295
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13896
llvm-svn: 251287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds support for using the "interrupt" attribute on Mips
for interrupt handling functions. At this time only mips32r2+ with the
o32 ABI with the static relocation model is supported. Unsupported
configurations will be rejected
Patch by Simon Dardis (+ clang-format & some trivial changes to follow the
LLVM coding standards by me).
Reviewers: mpf, dsanders
Subscribers: dsanders, vkalintiris, llvm-commits
Differential Revision: http://reviews.llvm.org/D10768
llvm-svn: 251286
|
|
|
|
|
|
|
|
| |
Bug https://llvm.org/bugs/show_bug.cgi?id=25318
Differential Revision: http://reviews.llvm.org/D14062
llvm-svn: 251285
|
|
|
|
|
|
| |
This means "memory with offset" and requires very little plumbing to get working. This fixes PR25317.
llvm-svn: 251280
|
|
|
|
| |
llvm-svn: 251278
|
|
|
|
|
|
|
|
|
|
| |
Otherwise value can be reused , despite its value could be changed - produces incorrect assembler.
https://llvm.org/bugs/show_bug.cgi?id=25270
Differential Revision: http://reviews.llvm.org/D14057
llvm-svn: 251275
|
|
|
|
|
|
|
|
|
|
| |
We didn't validate that the .word directive was given a sane value,
leading to crashes when we attempt to write out the object file.
Instead, perform some validation and issue a diagnostic pointing at the
start of the diagnostic.
llvm-svn: 251270
|
|
|
|
| |
llvm-svn: 251266
|
|
|
|
|
|
| |
Incorrect range test - found during fuzz testing.
llvm-svn: 251245
|
|
|
|
|
|
|
|
|
|
| |
When the target does not support these intrinsics they should be converted to a chain of scalar load or store operations.
If the mask is not constant, the scalarizer will build a chain of conditional basic blocks.
I added isLegalMaskedGather() isLegalMaskedScatter() APIs.
Differential Revision: http://reviews.llvm.org/D13722
llvm-svn: 251237
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using the MCU psABI, compiler-generated library calls should pass
some parameters in-register. However, since inreg marking for x86 is currently
done by the front end, it will not be applied to backend-generated calls.
This is a workaround for PR3997, which describes a similar issue for -mregparm.
Differential Revision: http://reviews.llvm.org/D13977
llvm-svn: 251223
|
|
|
|
|
|
|
|
| |
This adds support for the i?86-*-elfiamcu triple, which indicates the IAMCU psABI is used.
Differential Revision: http://reviews.llvm.org/D13977
llvm-svn: 251222
|
|
|
|
| |
llvm-svn: 251219
|
|
|
|
| |
llvm-svn: 251217
|
|
|
|
|
|
| |
Most 128-bit and 256-bit shuffles were manually matching UNPCK patterns - use lowerVectorShuffleWithUNPCK to be more thorough.
llvm-svn: 251211
|
|
|
|
|
|
| |
Use isShuffleEquivalent to match UNPCK shuffles - better support for build vector inputs.
llvm-svn: 251207
|
|
|
|
|
|
| |
array rather than pointer and size. NFC
llvm-svn: 251196
|
|
|
|
|
|
|
|
|
| |
This enables tail calls with thiscall, stdcall, vectorcall and
fastcall functions.
Differential Revision: http://reviews.llvm.org/D13999
llvm-svn: 251190
|
|
|
|
| |
llvm-svn: 251189
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for lowering to the XOP VPROT / VPROTI vector bit rotation instructions.
This has required changes to the DAGCombiner rotation pattern matching to support vector types - so far I've only changed it to support splat vectors, but generalising this further is feasible in the future.
Differential Revision: http://reviews.llvm.org/D13851
llvm-svn: 251188
|
|
|
|
| |
llvm-svn: 251160
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The logic here isn't straightforward because our support for
TargetOptions::GuaranteedTailCallOpt.
Also fix a bug where we were allowing tail calls to cdecl functions from
fastcall and vectorcall functions. We were special casing thiscall and
stdcall callers rather than checking for any convention that requires
clearing stack arguments before returning.
Reviewers: hans
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14024
llvm-svn: 251137
|
|
|
|
| |
llvm-svn: 251132
|
|
|
|
| |
llvm-svn: 251125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
saved registers
Summary:
When ARMFrameLowering::emitPopInst generates a "pop" instruction to restore the callee saved registers, it checks if the LR register is among them. If so, the function may decide to remove the basic block's terminator and replace it with a "pop" to the PC register instead of LR.
This leads to a problem when the block's terminator is preceded by a "llvm.debugtrap" call. The MI iterator points to the trap in such a case, which is also a terminator. If the function decides to restore LR to PC, it erroneously removes the trap.
Reviewers: asl, rengolin
Subscribers: aemerson, jfb, rengolin, dschuff, llvm-commits
Differential Revision: http://reviews.llvm.org/D13672
llvm-svn: 251123
|
|
|
|
| |
llvm-svn: 251122
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This ensures that BranchFolding (and similar) won't remove these blocks.
Also allow AsmPrinter::EmitBasicBlockStart to process MBBs which are
address-taken but do not have BBs that are address-taken, since otherwise
its call to getAddrLabelSymbolTableToEmit would fail an assertion on such
blocks. I audited the other callers of getAddrLabelSymbolTableToEmit
(and getAddrLabelSymbol); they all have BBs known to be address-taken
except for the call through getAddrLabelSymbol from
WinException::create32bitRef; that call is actually now unreachable, so
I've removed it and updated the signature of create32bitRef.
This fixes PR25168.
Reviewers: majnemer, andrew.w.kaylor, rnk
Subscribers: pgavlin, llvm-commits
Differential Revision: http://reviews.llvm.org/D13774
llvm-svn: 251113
|
|
|
|
|
|
| |
This reverts commit r250719. This introduced a codegen fault in SPEC2000.gcc, when compiled for Cortex-A53.
llvm-svn: 251108
|
|
|
|
|
|
|
|
| |
SHLLV_S.PH, SHLLV.QB, SHLLV_S.W, SHLL_S.W, SHRA.QB and SHRA_R.QB instructions
Differential Revision: http://reviews.llvm.org/D13929
llvm-svn: 251098
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turned out not to improve any of our benchmarks but occasionally led
to increased register pressure and spilling.
Only enabling for the Cyclone CPU as the results on the cortex CPUs
give mixed results.
Differential Revision: http://reviews.llvm.org/D13708
llvm-svn: 251038
|
|
|
|
|
|
| |
unused.
llvm-svn: 251035
|
|
|
|
|
|
| |
This removes the need to pass a hardcoded size in many places. NFC
llvm-svn: 251032
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR24686 identifies a problem where a relocation expression is invalid
when not all of the symbols in the expression can be locally
resolved. This causes the compiler to request a PC-relative half16ds
relocation, which is nonsensical for PowerPC. This patch recognizes
this situation and ensures we fail the assembly cleanly.
Test case provided by Anton Blanchard.
llvm-svn: 251027
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13945
llvm-svn: 251018
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed faiure:
LLVM ERROR: Cannot select: t33: i1 = select_cc t25, Constant:i32<0>, t45, t42, seteq:ch
added a test
Differential Revision: http://reviews.llvm.org/D13943
llvm-svn: 250996
|
|
|
|
|
|
|
|
| |
Clang runtime failure was reported.
Assertion failed: (isExtended() && "Type is not extended!"), function getTypeForEVT
I'll need to add a proper handling for PointerType in masked load/store intrinsics.
llvm-svn: 250995
|
|
|
|
|
|
|
| |
br_if shouldn't start with a dot.
div and rem went from prefix u/s to suffix.
llvm-svn: 250972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were the cause of a verifier error when building 7zip with
-verify-machineinstrs. Running 'make check' with the verifier
triggered the same error on the test here so i've updated the test
to run the verifier on one of its runs instead of adding a new one.
While looking at this code, there was a stale comment that these
instructions were only used for disassembly. This probably used to
be the case, but they are now used in the 'ARM load / store optimization pass' too.
This reapplies r242300 which was reverted in r242428 due to bot failures.
Ultimately those failures were spurious and completely unrelated to this commit. I reverted this
at the time because it was thought to be at fault.
llvm-svn: 250969
|
|
|
|
|
|
| |
BuildMI already adds these since they are defined correctly now.
llvm-svn: 250961
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There may be other use operands that also need their kill flags cleared.
This happens in a few tests when SIFoldOperands is moved after
PeepholeOptimizer.
PeepholeOptimizer rewrites cases that look like:
%vreg0 = ...
%vreg1 = COPY %vreg0
use %vreg1<kill>
%vreg2 = COPY %vreg0
use %vreg2<kill>
to use the earlier source to
%vreg0 = ...
use %vreg0
use %vreg0
Currently SIFoldOperands sees the copied registers, so there is
only one use. So far I haven't managed to come up with a test
that currently has multiple uses of a foldable VGPR -> VGPR copy.
llvm-svn: 250960
|
|
|
|
| |
llvm-svn: 250959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was checking for a variety of situations that should
never happen. This saves a tiny bit of compile time.
We should not be selecting instructions with invalid operands in the
first place. Most of the time for registers copys are inserted
to the correct operand register class.
For VOP3, since all operand types are supported and literal
constants never are, we just need to verify the constant bus
requirements (all immediates should be legal inline ones).
The only possibly tricky case to maybe worry about is if when
legalizing operands in moveToVALU with s_add_i32 and similar
instructions. If the original s_add_i32 had a literal constant
and we need to replace it with v_add_i32_e64 we would have an
unsupported literal operand. However, I don't think we should worry
about that because SIFoldOperands should handle folding literal
constant operands into the SALU instructions based on the uses.
At SIFoldOperands time, the legality and profitability of
operand types is a bit different.
llvm-svn: 250951
|
|
|
|
|
|
|
| |
When verifying constant bus restrictions, this wasn't catching
uses in implicit operands.
llvm-svn: 250948
|
|
|
|
|
|
|
| |
attribute. Clang incorrectly misses it on __muldc3 and friends and the
type system doesn't include it properly either.
llvm-svn: 250938
|
|
|
|
| |
llvm-svn: 250926
|
|
|
|
|
|
| |
parser and disassembler.
llvm-svn: 250911
|