| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Correctly parse end-of-statement tokens and handle preprocessor
end-of-line comments in ARM assembly processor.
Reviewers: rnk, majnemer
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D26152
llvm-svn: 285830
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Remove this pass from addMachineSSAOptimization() and register it unconditionally in through addPreRegAlloc(). This pass is required for generating correct PIC calls.
Reviewers: sdardis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26036
llvm-svn: 285814
|
| |
|
|
|
|
|
|
| |
GPRC and GPRC_NOR0 (or the 64bit equivalent) and not just the latter.
GPRC_NOR0 contains ZERO as alternative meaning of r0 and is therefore
not a true subclass of GPRC.
llvm-svn: 285813
|
| |
|
|
|
|
| |
labels. Silences an MSVC warning; NFC.
llvm-svn: 285806
|
| |
|
|
|
|
| |
SystemZAsmParser::parseOperand returns a bool, not an enum.
llvm-svn: 285800
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While bootstrapping Clang with recent `gcc 6.2.0` I found a bug related to misleading indentation.
I believe, a pair of `{}` was forgotten, especially given the above similar piece of code:
```
if (!RDef || !HII->isPredicable(*RDef)) {
Done = coalesceRegisters(RD, RegisterRef(S1));
if (Done) {
UpdRegs.insert(RD.Reg);
UpdRegs.insert(S1.getReg());
}
}
```
Reviewers: kparzysz
Differential Revision: https://reviews.llvm.org/D26204
llvm-svn: 285794
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This adds AVRISelLowering.cpp
Reviewers: arsenm, kparzysz
Subscribers: llvm-commits, modocache, japaric, wdng, beanz, mgorny
Differential Revision: https://reviews.llvm.org/D25034
llvm-svn: 285790
|
| |
|
|
|
|
|
|
| |
These interfaces are no longer used.
Differential Revision: https://reviews.llvm.org/D26222
llvm-svn: 285774
|
| |
|
|
|
|
|
|
|
|
| |
This is enough to compile and link but doesn't yet do anything particularly
useful. Once an ASM parser and printer are added in the next two patches, the
whole thing can be usefully tested.
Differential Revision: https://reviews.llvm.org/D23562
llvm-svn: 285770
|
| |
|
|
|
|
|
|
|
|
| |
For now, only add instruction definitions for basic ALU operations. Our
initial target is a working MC layer rather than codegen, so appropriate
SelectionDAG patterns will come later.
Differential Revision: https://reviews.llvm.org/D23561
llvm-svn: 285769
|
| |
|
|
| |
llvm-svn: 285768
|
| |
|
|
|
|
| |
This is already done with VGPR immediates and saves 4 bytes.
llvm-svn: 285765
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is the conservatively correct way because it's easy to
move or replace a scalar immediate. This was incorrect in the case
when the register class wasn't known from the static instruction
definition, but still needed to be an SGPR. The main example of this
is inlineasm has an SGPR constraint.
Also start verifying the register classes of inlineasm operands.
llvm-svn: 285762
|
| |
|
|
|
|
|
| |
These are only used in the spill to VMEM path. Move them to
the one use.
llvm-svn: 285756
|
| |
|
|
|
|
|
|
|
|
| |
Instructions with a 32-bit base encoding with an optional
32-bit literal encoded after them report their size as 4
for the disassembler. Consider these when computing the
MachineInstr size. This fixes problems caused by size estimate
consistency in BranchRelaxation.
llvm-svn: 285743
|
| |
|
|
|
|
|
|
| |
For example, rename s6Ext to s6_0Ext. The names for shifted integers
include the underscore and this will make the naming consistent. It
also exposed a few duplicates that were removed.
llvm-svn: 285728
|
| |
|
|
|
|
|
|
|
|
|
| |
This will prevent following regression when enabling i16 support (D18049):
test/CodeGen/AMDGPU/ctlz.ll
test/CodeGen/AMDGPU/ctlz_zero_undef.ll
Differential Revision: https://reviews.llvm.org/D25802
llvm-svn: 285716
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This contains just enough for lib/Target/RISCV to compile. Notably a basic
RISCVTargetMachine and RISCVTargetInfo. At this point you can attempt llc
-march=riscv32 myinput.ll and will find it fails due to the lack of
MCAsmInfo.
See http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html for
further discussion
Differential Revision: https://reviews.llvm.org/D23560
llvm-svn: 285712
|
| |
|
|
| |
llvm-svn: 285711
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As it stands, the OperandMatchResultTy is only included in the generated
header if there is custom operand parsing. However, almost all backends
make use of MatchOperand_Success and friends from OperandMatchResultTy for
e.g. parseRegister. This is a pain when starting an AsmParser for a new
backend that doesn't yet have custom operand parsing. Move the enum to
MCTargetAsmParser.h.
This patch is a prerequisite for D23563
Differential Revision: https://reviews.llvm.org/D23496
llvm-svn: 285705
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wanted to implement this as a target independent expansion, however when
targets say they want to expand FP_TO_FP16 what they actually want is
the unsafe math expansion when possible and expansion to a libcall in all
other cases.
The only way to make this work as a target independent would be to add logic
to target's TargetLowering construction to mark theses nodes as Expand when
LegalizeDAG can use the unsafe expansion and mark them as LibCall when it
cannot. I think this would be possible, but I think it would be too fragile
and complex as it would require targets to keep their expansion logic up
to date with the code in LegalizeDAG.
Reviewers: bogner, ab, t.p.northover, arsenm
Subscribers: wdng, llvm-commits, nhaehnle
Differential Revision: https://reviews.llvm.org/D25999
llvm-svn: 285704
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Reapplying r284580 and r285917 with fix and testing to ensure emitted jump tables for Thumb-1 have 4-byte alignment]
The TBB and TBH instructions in Thumb-2 allow jump tables to be compressed into sequences of bytes or shorts respectively. These instructions do not exist in Thumb-1, however it is possible to synthesize them out of a sequence of other instructions.
It turns out this sequence is so short that it's almost never a lose for performance and is ALWAYS a significant win for code size.
TBB example:
Before: lsls r0, r0, #2 After: add r0, pc
adr r1, .LJTI0_0 ldrb r0, [r0, #6]
ldr r0, [r0, r1] lsls r0, r0, #1
mov pc, r0 add pc, r0
=> No change in prologue code size or dynamic instruction count. Jump table shrunk by a factor of 4.
The only case that can increase dynamic instruction count is the TBH case:
Before: lsls r0, r4, #2 After: lsls r4, r4, #1
adr r1, .LJTI0_0 add r4, pc
ldr r0, [r0, r1] ldrh r4, [r4, #6]
mov pc, r0 lsls r4, r4, #1
add pc, r4
=> 1 more instruction in prologue. Jump table shrunk by a factor of 2.
So there is an argument that this should be disabled when optimizing for performance (and a TBH needs to be generated). I'm not so sure about that in practice, because on small cores with Thumb-1 performance is often tied to code size. But I'm willing to turn it off when optimizing for performance if people want (also note that TBHs are fairly rare in practice!)
llvm-svn: 285690
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D26077
llvm-svn: 285684
|
| |
|
|
|
|
|
| |
This patch corresponds to review https://reviews.llvm.org/D26095.
Committing on behalf of Tony Jiang.
llvm-svn: 285681
|
| |
|
|
| |
llvm-svn: 285659
|
| |
|
|
| |
llvm-svn: 285654
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Generate the slowest possible codepath for noopt CodeGen. Even trying to be
clever with the negated jump can cause out-of-range jumps. Use a wide branch
instead. Although the code is modelled simplistically, the later optimizations
would recombine the branching into `cbz` if possible. This re-enables the
previous optimization as well as hopefully gives us working code in all cases.
Addresses PR30356!
llvm-svn: 285649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This has been replaced by the NVPTXInferAddressSpaces pass. We've had
the new one as the default with the old one accessible via a flag for
some months now, and we've had no problems.
Reviewers: tra
Subscribers: llvm-commits, jholewinski, jingyue, mgorny
Differential Revision: https://reviews.llvm.org/D26165
llvm-svn: 285642
|
| |
|
|
|
|
|
| |
This patch corresponds to review https://reviews.llvm.org/D26072.
Committing on behalf of Sean Fertile.
llvm-svn: 285627
|
| |
|
|
| |
llvm-svn: 285615
|
| |
|
|
| |
llvm-svn: 285614
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introducing "k" and "Yk" constraints for extended inline assembly, enabling use of AVX512 masked vectorized instructions.
Commit on behalf of mharoush
Extending inline assembly support, compatible with GCC as folowing:
"k" constraint hints the compiler to select any of AVX512 k0-k7 registers.
"Yk" constraint is a subset of "k" excluding k0 which is not allowd to be used as a mask.
Reviewer: 1. rnk
Differential Revision: https://reviews.llvm.org/D25062
llvm-svn: 285591
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes Bug 30808.
Note that passing subtarget information to predicates seems too complicated, so gfx8-specific def smrd_offset_20 introduced.
Old gfx6/7-specific def renamed to smrd_offset_8 for clarity.
Lit tests updated.
Differential Revision: https://reviews.llvm.org/D26085
llvm-svn: 285590
|
| |
|
|
| |
llvm-svn: 285588
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements two changes:
- Move processor feature definition into a new file SystemZFeatures.td,
and provide explicit lists of supported and unsupported features for
each level of the z/Architecture. This allows specifying unsupported
features in the scheduler definition files for each processor.
- Add optional aliases for the -mcpu processor names according to the
level of the z/Architecture, for compatibility with other compilers
on the platform. The supported aliases are:
-mcpu=arch8 equals -mcpu=z10
-mcpu=arch9 equals -mcpu=z196
-mcpu=arch10 equals -mcpu=zEC12
-mcpu=arch11 equals -mcpu=z13
llvm-svn: 285577
|
| |
|
|
|
|
|
|
|
|
|
| |
The LEFR/LFER pseudos are aliases for vector instructions and should
therefore be guared by FeatureVector. If they aren't, the TableGen
scheduler definition checking might complain that there is no data
for those pseudos for pre-z13 machines.
No functional change intended.
llvm-svn: 285576
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when using an instruction that is not supported on the
currently selected architecture, the LLVM assembler is likely to
diagnose an "invalid operand" instead of a "missing feature".
This is because many operands require a custom parser in order to
be processed correctly, and if an instruction is not available
according to the current feature set, the generated parser code
will also not detect the associated custom operand parsers.
Fixed by temporarily enabling all features while parsing operands.
The missing features will then be correctly detected when actually
parsing the instruction itself.
llvm-svn: 285575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM currently treats the first operand of MVCK as if it were a
regular base+index+displacement address. However, it is in fact
a base+displacement combined with a length register field.
While the two might look syntactically similar, there are two
semantic differences:
- %r0 is a valid length register, even though it cannot be used
as an index register.
- In an expression with just a single register like 0(%rX), the
register is treated as base with normal addresses, while it is
treated as the length register (with an empty base) for MVCK.
Fixed by adding a new operand parser class BDRAddr and reworking
the assembler parser to distinguish between address + length
register operands and regular addresses.
llvm-svn: 285574
|
| |
|
|
|
|
|
| |
NFC.
Review: Ulrich Weigand.
llvm-svn: 285566
|
| |
|
|
|
|
|
|
|
|
| |
There is a bug describing poor cost model for floating point operations:
Bug 29083 - [X86][SSE] Improve costs for floating point operations. This
patch is the second one in series of patches dealing with cost model.
Differential Revision: https://reviews.llvm.org/D25722
llvm-svn: 285564
|
| |
|
|
|
|
| |
started from shuffles.
llvm-svn: 285546
|
| |
|
|
|
|
|
|
| |
legacy intrinsics to select EVEX encoded instructions when available.
This removes a couple tablegen classes that become unused after this change. Another class gained an additional parameter to allow PMADDUBSW to specify a different result type from its input type.
llvm-svn: 285515
|
| |
|
|
|
|
| |
This bug was introduced in r285501.
llvm-svn: 285510
|
| |
|
|
|
|
|
|
| |
intrinsics can select EVEX encoded instructions when available.
This requires a minor rename of the instructions due to the use of different tablegen classes and how the names are concatenated.
llvm-svn: 285501
|
| |
|
|
|
|
|
|
| |
Masked form of FMA should be omitted in this optimization.
Differential Revision: https://reviews.llvm.org/D25984
llvm-svn: 285492
|
| |
|
|
|
|
| |
I'm guessing at how it is supposed to be printed
llvm-svn: 285490
|
| |
|
|
|
|
|
|
|
|
|
| |
- Fix doxygen file comment
- reduce indentation in loop
- Factor out some common subexpressions
- Move independent helper function out of class
- Fix Changed flag (this is not strictly NFC but a bugfix, but the flag
seems ignored anyway)
llvm-svn: 285488
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Flat instruction can return out of order, so we need always need to wait
for all the outstanding flat operations.
Reviewers: tony-tye, arsenm
Subscribers: kzhuravl, wdng, nhaehnle, llvm-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D25998
llvm-svn: 285479
|
| |
|
|
|
|
|
| |
Set isReturn, remove hasSideEffects. Also remove
hasCtrlDep, I'm not really sure what that does.
llvm-svn: 285476
|
| |
|
|
|
|
|
|
|
|
| |
Also add glc bit to the scalar loads since they exist on VI
and change the caching behavior.
This currently has an assembler bug where the glc bit is incorrectly
accepted on SI/CI which do not have it.
llvm-svn: 285463
|