| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
WriteFRcp/WriteFRsqrt are split to support scalar, XMM and YMM/ZMM instructions.
WriteFSqrt is split into single/double/long-double sizes and scalar, XMM, YMM and ZMM instructions.
This removes all InstrRW overrides for these instructions.
NOTE: There were a couple of typos in the Znver1 model - notably a 1cy throughput for SQRT that is highly unlikely and doesn't tally with Agner.
NOTE: I had to add Agner's numbers for several targets for WriteFSqrt80.
llvm-svn: 331629
|
| |
|
|
|
|
|
|
| |
MVCLoop clobbers CC (since it emits a compare/branch), but this was not
modelled.
Review: Ulrich Weigand
llvm-svn: 331627
|
| |
|
|
|
|
|
|
| |
automatically. NFC
The old behavior return the value 0, which is error prone.
llvm-svn: 331614
|
| |
|
|
| |
llvm-svn: 331611
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VRCP14PS/VRSQRT14PS
Summary:
The legacy VRCPPS/VRSQRTPS instructions aren't available in 512-bit versions. The new increased precision versions are. So we can use those to implement v16f32 reciprocal estimates.
For KNL CPUs we can probably use VRCP28PS/VRSQRT28PS and avoid the NR step altogether, but I leave that for a future patch.
Reviewers: spatel
Reviewed By: spatel
Subscribers: RKSimon, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D46498
llvm-svn: 331606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
extending loads
Summary:
Previously, a extending load was represented at (G_*EXT (G_LOAD x)).
This had a few drawbacks:
* G_LOAD had to be legal for all sizes you could extend from, even if
registers didn't naturally hold those sizes.
* All sizes you could extend from had to be allocatable just in case the
extend went missing (e.g. by optimization).
* At minimum, G_*EXT and G_TRUNC had to be legal for these sizes. As we
improve optimization of extends and truncates, this legality requirement
would spread without considerable care w.r.t when certain combines were
permitted.
* The SelectionDAG importer required some ugly and fragile pattern
rewriting to translate patterns into this style.
This patch changes the representation to:
* (G_[SZ]EXTLOAD x)
* (G_LOAD x) any-extends when MMO.getSize() * 8 < ResultTy.getSizeInBits()
which resolves these issues by allowing targets to work entirely in their
native register sizes, and by having a more direct translation from
SelectionDAG patterns.
Each extending load can be lowered by the legalizer into separate extends
and loads, however a target that supports s1 will need the any-extending
load to extend to at least s8 since LLVM does not represent memory accesses
smaller than 8 bit. The legalizer can widenScalar G_LOAD into an
any-extending load but sign/zero-extending loads need help from something
else like a combiner pass. A follow-up patch that adds combiner helpers for
for this will follow.
The new representation requires that the MMO correctly reflect the memory
access so this has been corrected in a couple tests. I've also moved the
extending loads to their own tests since they are (mostly) separate opcodes
now. Additionally, the re-write appears to have invalidated two tests from
select-with-no-legality-check.mir since the matcher table no longer contains
loads that result in s1's and they aren't legal in AArch64 anymore.
Depends on D45540
Reviewers: ab, aditya_nandakumar, bogner, rtereshin, volkan, rovka, javed.absar
Reviewed By: rtereshin
Subscribers: javed.absar, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D45541
llvm-svn: 331601
|
| |
|
|
| |
llvm-svn: 331599
|
| |
|
|
|
|
|
|
|
|
| |
dyn_cast.
Inspired by r331508, I did a grep and found these.
Mostly just change from dyn_cast to cast. Some cases also showed a dyn_cast result being converted to bool, so those I changed to isa.
llvm-svn: 331577
|
| |
|
|
| |
llvm-svn: 331564
|
| |
|
|
| |
llvm-svn: 331553
|
| |
|
|
|
|
|
|
|
| |
- Predicate D16 patterns on this new feature
- Added this new feature to gfx900/2/4
Differential Revision: https://reviews.llvm.org/D46366
llvm-svn: 331551
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Adding support for Fast flags in the SDNode to leverage fast math sub flag usage.
Reviewers: spatel, arsenm, jbhateja, hfinkel, escha, qcolombet, echristo, wristow, javed.absar
Reviewed By: spatel
Subscribers: llvm-commits, rampitec, nhaehnle, tstellar, FarhanaAleen, nemanjai, javed.absar, jbhateja, hfinkel, wdng
Differential Revision: https://reviews.llvm.org/D45710
llvm-svn: 331547
|
| |
|
|
|
|
| |
Filled in the missing values from Btver2 SoG or Agner
llvm-svn: 331546
|
| |
|
|
|
|
| |
overrides.
llvm-svn: 331543
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: They are not consistent with other microarchitectures.
Reviewers: gchatelet
Subscribers: tschuett, llvm-commits
Differential Revision: https://reviews.llvm.org/D46434
llvm-svn: 331532
|
| |
|
|
|
|
| |
Rename scalar and XMM versions, this is to match/simplify an upcoming change to split MUL/DIV/SQRT scalar/xmm/ymm/zmm classes.
llvm-svn: 331531
|
| |
|
|
| |
llvm-svn: 331528
|
| |
|
|
| |
llvm-svn: 331527
|
| |
|
|
|
|
|
|
|
|
| |
And eliminatw the duplication of those instructions for microMIPS32r6.
Reviewers: smaksimovic, abeserminji, atanasyan
Differential Revision: https://reviews.llvm.org/D46117
llvm-svn: 331526
|
| |
|
|
| |
llvm-svn: 331525
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a custom lowering for ISD::MULH{S,U} used on divide by
constant optimization (DAGCombiner::BuildSDIV and DAGCombiner::BuildUDIV).
New patterns for smull and umull are added, so AArch64ISD::{S,U}MULL
can be correctly lowered to smull2 and umull2.
Reviewed By: SjoerdMeijer
Differential Revision: https://reviews.llvm.org/D46009
llvm-svn: 331522
|
| |
|
|
| |
llvm-svn: 331518
|
| |
|
|
|
|
|
|
| |
Split off from SchedWriteFAdd for fp rounding/bit-manipulation instructions.
Fixes an issue on btver2 which only had the ymm version using the JSTC pipe instead of JFPA.
llvm-svn: 331515
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes is possible to have R600RegisterInfo and SIRegisterInfo
not inherit from AMDGPURegisterInfo.
Reviewers: arsenm, nhaehnle
Reviewed By: arsenm
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D46280
llvm-svn: 331490
|
| |
|
|
| |
llvm-svn: 331489
|
| |
|
|
|
|
|
|
| |
Avoids extra entries in the class tables.
Found a typo that missed the MMX_PHSUBSW instruction.
llvm-svn: 331488
|
| |
|
|
|
|
| |
not SchedWriteVecALU.
llvm-svn: 331473
|
| |
|
|
|
|
|
|
| |
scheduler classes
This took a bit of extra work as on Intel targets the old (V)PSLLDrr/(V)PSLLDrm style instructions act differently - I ended up creating WriteVecShiftImm classes for XMM/YMM/ZMM vector shift by immediate and retaining WriteVecShift as the default (used only by MMX) plus WriteVecShiftX/WriteVecShiftY. X86SchedWriteWidths hides most of this thank goodness.
llvm-svn: 331472
|
| |
|
|
| |
llvm-svn: 331453
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By default LLVM thinks very large vectors get aligned to their size when
passed across functions. Unfortunately no-one told the ARM backend so it
doesn't trigger stack realignment and so accesses can cause the usual
misalignment issues (e.g. a data abort).
This changes the ABI alignment to the stack alignment, which in practice
(and as a bonus) also coincides with the alignment "natural" vectors get.
llvm-svn: 331451
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is one of the initial commit of "RFC: Devirtualization v2" proposal:
https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing
Reviewers: rsmith, amharc, kuhar, sanjoy
Subscribers: arsenm, nhaehnle, javed.absar, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45111
llvm-svn: 331448
|
| |
|
|
| |
llvm-svn: 331446
|
| |
|
|
|
|
|
|
| |
YMM/ZMM scheduler classes
Also retagged VDBPSADBW instructions as SchedWritePSADBW instead of SchedWriteVecIMul which matches the behaviour on SkylakeServer (the only thing that supports it...)
llvm-svn: 331445
|
| |
|
|
| |
llvm-svn: 331443
|
| |
|
|
|
|
| |
https://reviews.llvm.org/D46356
llvm-svn: 331439
|
| |
|
|
|
|
|
| |
actually encounter constants wider than 64-bits. Add the guard to prevent
tripping the assert.
llvm-svn: 331420
|
| |
|
|
|
|
|
|
|
|
|
| |
Sinking the and closer to a compare against zero is beneficial on PPC as it
allows us to emit record-form instructions. In the future, we may expand this
to a larger set of operations that feed compares against zero since PPC has
lots of record-form instructions.
Differential revision: https://reviews.llvm.org/D46060
llvm-svn: 331416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CTR loops pass will insert the decrementing branch instruction in an exiting
block for the loop being transformed. However if that block is part of another
loop as well (whether a nested loop or with irreducible CFG), it is not valid
to use that exiting block. In fact, if the loop hass irreducible CFG, we don't
bother analyzing it and we just bail on the transformation. In practice, this
doesn't lead to a noticeable reduction in the number of loops transformed by
this pass.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37229
Differential Revision: https://reviews.llvm.org/D46162
llvm-svn: 331410
|
| |
|
|
|
|
| |
The entries were being bound to the wrong class.
llvm-svn: 331388
|
| |
|
|
|
|
| |
and YMM/ZMM scheduler classes
llvm-svn: 331386
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D46355
llvm-svn: 331384
|
| |
|
|
|
|
|
| |
224a839fcbbead221f872cd32a1dd0c308d37299".
Author: FarhanaAleen
llvm-svn: 331383
|
| |
|
|
|
|
| |
classes with more common default values
llvm-svn: 331380
|
| |
|
|
|
|
| |
This reverts commit 6b97d2995566b4dddd6bf0d75579ff44501d4494.
llvm-svn: 331371
|
| |
|
|
|
|
| |
to X86SchedWriteWidths.
llvm-svn: 331369
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: performAddCombine should run after DAG is legalized; Otherwise generic optimization
in the DAGCombiner can optimize an addcarry+trunc into an addcarry instruction with
illegal types.
Author: FarhanaAleen
Reviewed By: rampitec
Subscribers: llvm-commits, AMDGPU
Differential Revision: https://reviews.llvm.org/D46337
llvm-svn: 331368
|
| |
|
|
| |
llvm-svn: 331367
|
| |
|
|
|
|
|
|
| |
Without the rebase mess.
https://reviews.llvm.org/D46356
llvm-svn: 331362
|
| |
|
|
|
|
| |
Intel models were targeting x87 instead of packed sse.
llvm-svn: 331360
|
| |
|
|
|
|
| |
It contains unrelated changes.
llvm-svn: 331357
|