| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
one place.
A new function getOpcodeForSpill should now be the only place to get
the opcode for a given spilled register.
Differential Revision: https://reviews.llvm.org/D43086
llvm-svn: 328556
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
llvm-objdump now disassembles unrecognised opcodes as data, using
the .long directive. We treat unrecognised opcodes as being 32 bit
values, so move along 4 bytes rather than the single byte which
previously resulted in a cascade of bogus disassembly following an
unrecognised opcode.
While no solution can always disassemble code that contains
embedded data correctly this provides a significant improvement.
The disassembler will now cope with an arbitrary length section
as it no longer truncates it to a multiple of 4 bytes, and will
use the .byte directive for trailing bytes.
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D44685
llvm-svn: 328553
|
| |
|
|
|
|
| |
We still need to account for how Jaguar passes data from GPR -> XMM, which isn't as clean as XMM -> GPR.....
llvm-svn: 328551
|
| |
|
|
|
|
| |
Target/TargetLoweringObjectFile on a CodeGen header
llvm-svn: 328549
|
| |
|
|
|
|
| |
header
llvm-svn: 328548
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch contains severals changes needed to pipeline an example
that was transformed so that a Phi with a subreg is converted to
copies.
The pipeliner wasn't working for a couple of reasons.
- The RecMII was 3 instead of 2 due to the extra copies.
- Copy instructions contained a latency of 1.
- The node order algorithm was not choosing the best "bottom"
node, which caused an instruction to be scheduled that had a
predecessor and successor already scheduled.
- Updated the Hexagon Machine Scheduler to check if the node is
latency bound when adding the cost for a 0-latency dependence.
The RecMII was 3 because the computation looks at the number of
nodes in the recurrence. The extra copy is an extra node but
it shouldn't increase the latency. The new RecMII computation
looks at the latency of the instructions in the recurrence. We
changed the latency of the dependence of a copy to 0. The latency
computation for the copy also checks the use of the copy (similar
to a reg_sequence).
The node order algorithm was not choosing the last instruction
in the recurrence for a bottom up traversal. This was when the
last instruction is a copy. A check was added when choosing the
instruction to check for NodeNum if the maxASAP is the same. This
means that the scheduler will not end up with another node in
the recurrence that has both a predecessor and successor already
scheduled.
The cost computation in Hexagon Machine Scheduler adds cost when
an instruction can be packetized with a zero-latency instruction.
We should only do this if the schedule is latency bound.
Patch by Brendon Cahoon.
llvm-svn: 328542
|
| |
|
|
| |
llvm-svn: 328541
|
| |
|
|
|
|
| |
JALU0 for GPR PRF write)
llvm-svn: 328536
|
| |
|
|
| |
llvm-svn: 328506
|
| |
|
|
|
|
|
|
| |
Account for the "+i" integer pipe transfer cost (1cy use of JALU0 for GPR PRF write)
This also adds missing vcvttss2si tests
llvm-svn: 328505
|
| |
|
|
|
|
| |
These should match the YMM MOVDUP/ PERMILPD/PERMILPS + SHUFPD/SHUFPS shuffles instead of using the WriteFShuffle defaults.
llvm-svn: 328501
|
| |
|
|
|
|
| |
The xmm sd/pd versions were using the WriteFSQRT default which is modelled on sqrtss/sqrtps
llvm-svn: 328497
|
| |
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D44820
Change-Id: I732979e2964006aa15d78a333d8886e6855f319a
llvm-svn: 328496
|
| |
|
|
|
|
| |
Both the AGUs and schedule pipes are double pumped for 256-bit instructions as well as the functional units which we already model.
llvm-svn: 328491
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of i32"
This broke Chromium (see crbug.com/825748). It looks like mstorsjo's follow-up
patch at D44876 fixes this, but let's revert back to green for now until that's
ready to land.
(Also reverts r328443.)
> Both GCC and MSVC only look at the low byte of a boolean when it is
> passed.
llvm-svn: 328482
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44819
llvm-svn: 328478
|
| |
|
|
| |
llvm-svn: 328474
|
| |
|
|
|
|
|
|
| |
SandyBridge/Haswell/Broadwell/Skylake scheduler models.
I've used Agner's data as best I could to get the values to converge on.
llvm-svn: 328473
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 328472
|
| |
|
|
| |
llvm-svn: 328471
|
| |
|
|
|
|
| |
generated scheduler classes will merge.
llvm-svn: 328470
|
| |
|
|
|
|
| |
They were backwards.
llvm-svn: 328469
|
| |
|
|
|
|
| |
the same generated scheduler class.
llvm-svn: 328468
|
| |
|
|
|
|
| |
to share the same generated scheduler class.
llvm-svn: 328466
|
| |
|
|
|
|
|
|
| |
for Skylake.
This matches Agner's data and is consistent with what the EVEX instructions were doing on SKX.
llvm-svn: 328465
|
| |
|
|
| |
llvm-svn: 328460
|
| |
|
|
| |
llvm-svn: 328458
|
| |
|
|
|
|
|
|
| |
(D44687)
Reviewed by @javed.absar
llvm-svn: 328457
|
| |
|
|
| |
llvm-svn: 328456
|
| |
|
|
|
|
|
|
| |
optionally starting with 'Y' instead of 'V'
These bad regexs were introduced by r328435
llvm-svn: 328454
|
| |
|
|
|
|
| |
Not that it makes a difference to current cost values, but will when we try to better model GPR-SIMD transfer costs
llvm-svn: 328453
|
| |
|
|
| |
llvm-svn: 328452
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add fdiv costs for Goldmont using table 16-17 of the Intel Optimization Manual. Also add overrides for FSQRT for Goldmont and Silvermont.
Reviewers: RKSimon
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44644
llvm-svn: 328451
|
| |
|
|
|
|
|
|
|
|
| |
add 1uop for memory folds for Intel models
The Intel models need an extra 1uop for memory folded instructions, plus a lot of instructions take a non-default memory latency which should allow us to use the multiclass a lot more to tidy things up.
Differential Revision: https://reviews.llvm.org/D44840
llvm-svn: 328446
|
| |
|
|
| |
llvm-svn: 328444
|
| |
|
|
| |
llvm-svn: 328443
|
| |
|
|
|
|
| |
regex matches to reduce compile time
llvm-svn: 328435
|
| |
|
|
|
|
| |
regex matches to reduce compile time
llvm-svn: 328434
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LLVM defaults to the newer .init_array/.fini_array scheme for static
constructors rather than the less desirable .ctors/.dtors (the UseCtors
flag defaults to false). This wasn't being respected in the RISC-V
backend because it fails to call TargetLoweringObjectFileELF::InitializeELF with the the appropriate
flag for UseInitArray.
This patch fixes this by implementing RISCVELFTargetObjectFile and overriding its Initialize method to call
InitializeELF(TM.Options.UseInitArray).
Reviewers: asb, apazos
Reviewed By: asb
Subscribers: mgorny, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, llvm-commits
Differential Revision: https://reviews.llvm.org/D44750
llvm-svn: 328433
|
| |
|
|
|
|
| |
matches to reduce compile time
llvm-svn: 328432
|
| |
|
|
|
|
| |
regex matches to reduce compile time
llvm-svn: 328431
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.
Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches.
Reviewers: kparzysz
Reviewed By: kparzysz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44857
llvm-svn: 328430
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.
Reviewers: tstellar, RKSimon, arsenm
Reviewed By: arsenm
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D44856
llvm-svn: 328429
|
| |
|
|
|
|
|
|
| |
attribute.
This reduces the size of llvm-mc by at least 150k since we no longer have to multiply the attribute across 7 tables.
llvm-svn: 328416
|
| |
|
|
|
|
| |
The 3DNow instructions are encoded a little weird, but we can still represent it as an opcode map.
llvm-svn: 328410
|
| |
|
|
|
|
|
|
| |
These nodes only use the lower 32 bits of their inputs so we can use SimplifyDemandedBits to simplify them.
Differential Revision: https://reviews.llvm.org/D44375
llvm-svn: 328405
|
| |
|
|
|
|
| |
Should be NFC since nothing used the enum value. The instruction descriptions are generated from tablegen which had the correct value.
llvm-svn: 328398
|
| |
|
|
|
|
| |
ValueTypes.h is implemented in IR already.
llvm-svn: 328397
|
| |
|
|
|
|
|
|
|
| |
This is used by llvm tblgen as well as by LLVM Targets, so the only
common place is Support for now. (maybe we need another target for these
sorts of things - but for now I'm at least making them correct & we can
make them better if/when people have strong feelings)
llvm-svn: 328395
|
| |
|
|
|
|
|
|
| |
This includes llvm-c/TargetMachine.h which is logically part of
libTarget (since libTarget implements llvm-c/TargetMachine.h's
functions).
llvm-svn: 328394
|