| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
In restoreLatency, replace range-for loop with std::find.
Patch by Jyotsna Verma.
llvm-svn: 328574
|
| |
|
|
|
|
| |
Account for the "+i" integer pipe transfer cost (1cy use of JALU0 for GPR PRF write)
llvm-svn: 328573
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Re-lands r328386 and r328443, reverting r328482.
Incorporates fixes from @mstorsjo in D44876 (thanks!) so that small
parameters in i8 and i16 do not end up in the SysV register parameters
(EDI, ESI, etc).
I added tests for how we receive small parameters, since that is the
important part. It's always safe to store more bytes than will be read,
but the assumptions you make when loading them are what really matter.
I also tested this by self-hosting clang and it passed tests on win64.
Reviewers: mstorsjo, hans
Subscribers: hiraditya, mstorsjo, llvm-commits
Differential Revision: https://reviews.llvm.org/D44900
llvm-svn: 328570
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(PR36881)
Give the bit count instructions their own scheduler classes instead of forcing them into existing classes.
These were mostly overridden anyway, but I had to add in costs from Agner for silvermont and znver1 and the Fam16h SoG for btver2 (Jaguar).
Differential Revision: https://reviews.llvm.org/D44879
llvm-svn: 328566
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: dblaikie, RKSimon, robertlytton
Reviewed By: robertlytton
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44875
llvm-svn: 328564
|
| |
|
|
|
|
|
|
|
| |
Legalize and emit code for quad-precision floating point operation xscvdpqp
and add option to guard the quad precision operation support.
Differential Revision: https://reviews.llvm.org/D44746
llvm-svn: 328558
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|