Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
3d9abfc9 |
| 31-Aug-2024 |
Philip Reames <preames@rivosinc.com> |
Consolidate all IR logic for getting the identity value of a reduction [nfc]
This change merges the three different places (at the IR layer) for finding the identity value of a reduction into a sing
Consolidate all IR logic for getting the identity value of a reduction [nfc]
This change merges the three different places (at the IR layer) for finding the identity value of a reduction into a single copy. This depends on several prior commits which fix ommissions and bugs in the distinct copies, but this patch itself should be fully non-functional.
As the new comments and naming try to make clear, the identity value is a property of the @llvm.vector.reduce.* intrinsic, not of e.g. the recurrence descriptor. (We still provide an interface for clients using recurrence descriptors, but the implementation simply translates to the intrinsic which each corresponds to.)
As a note, the getIntrinsicIdentity API does not support fminnum/fmaxnum or fminimum/fmaximum which is why we still need manual logic (but at least only one copy of manual logic) for those cases.
show more ...
|
Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
4169338e |
| 28-Jun-2024 |
Nikita Popov <npopov@redhat.com> |
[IR] Don't include Module.h in Analysis.h (NFC) (#97023)
Replace it with a forward declaration instead. Analysis.h is pulled in
by all passes, but not all passes need to access the module.
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
39197691 |
| 05-Jan-2023 |
Nikita Popov <npopov@redhat.com> |
[IVDescriptorsTest] Convert to opaque pointers (NFC)
The LoopWithScalableTypes test is removed, because it is testing a situation that cannot occur with opaque pointers. If we convert this test to o
[IVDescriptorsTest] Convert to opaque pointers (NFC)
The LoopWithScalableTypes test is removed, because it is testing a situation that cannot occur with opaque pointers. If we convert this test to opaque pointers, it will not contain any scalable types at all.
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5 |
|
#
d9c52c31 |
| 04-Nov-2022 |
Karthik Senthil <karthik.senthil@intel.com> |
[LV][IVDescriptors] Fix recurrence identity element for FMin and FMax reductions
For a min and max reduction idioms, the identity (i.e. neutral) element should be datatype's highest and lowest possi
[LV][IVDescriptors] Fix recurrence identity element for FMin and FMax reductions
For a min and max reduction idioms, the identity (i.e. neutral) element should be datatype's highest and lowest possible values respectively. Current implementation in IVDescriptors incorrectly returns -Inf for FMin reduction and +Inf for FMax reduction. This patch fixes this bug which was causing incorrect reduction computation results in loops vectorized by LV.
Differential Revision: https://reviews.llvm.org/D137220
show more ...
|
Revision tags: llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
#
1badfbb4 |
| 01-Feb-2022 |
David Sherwood <david.sherwood@arm.com> |
Fix incorrect TypeSize->uint64_t cast in InductionDescriptor::isInductionPHI
The code was relying upon the implicit conversion of TypeSize to uint64_t and assuming the type in question was always fi
Fix incorrect TypeSize->uint64_t cast in InductionDescriptor::isInductionPHI
The code was relying upon the implicit conversion of TypeSize to uint64_t and assuming the type in question was always fixed. However, I discovered an issue when running the canon-freeze pass with some IR loops that contains scalable vector types. I've changed the code to bail out if the size is unknown at compile time, since we cannot compute whether the step is a multiple of the type size or not.
I added a test here:
Transforms/CanonicalizeFreezeInLoops/phis.ll
Differential Revision: https://reviews.llvm.org/D118696
show more ...
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3 |
|
#
912b3b03 |
| 20-Jun-2021 |
Jim Lin <jim@andestech.com> |
[IVDescriptors] Fix comment that getUnsafeAlgebraInst has been renamed to getExactFPMathInst
https://reviews.llvm.org/rG36a489d194750dc888f214240e9dec9122ca1f0e renamed the function call in the test
[IVDescriptors] Fix comment that getUnsafeAlgebraInst has been renamed to getExactFPMathInst
https://reviews.llvm.org/rG36a489d194750dc888f214240e9dec9122ca1f0e renamed the function call in the test from getUnsafeAlgebraInst to getExactFPMathInst.
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D104441
show more ...
|
Revision tags: llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
#
36a489d1 |
| 04-Mar-2021 |
Sanjay Patel <spatel@rotateright.com> |
[Analysis][LoopVectorize] rename "Unsafe" variables/methods; NFC
Similar to b3a33553aec7, but this shows a TODO and a potential miscompile is already present.
We are tracking an FP instruction that
[Analysis][LoopVectorize] rename "Unsafe" variables/methods; NFC
Similar to b3a33553aec7, but this shows a TODO and a potential miscompile is already present.
We are tracking an FP instruction that does *not* have FMF (reassoc) properties, so calling that "Unsafe" seems opposite of the common reading.
I also removed one getter method by rolling the null check into the access. Further simplification may be possible.
The motivation is to clean up the interactions between FMF and function-level attributes in these classes and their callers.
The new test shows that there is an existing bug somewhere in the callers. We assumed that the original code was fully 'fast' and so we produced IR with 'fast' even though it was just 'reassoc'.
show more ...
|
Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
#
7ee6c402 |
| 14-Oct-2020 |
Roman Lebedev <lebedev.ri@gmail.com> |
Revert "Reland "[SCEV] Model ptrtoint(SCEVUnknown) cast not as unknown, but as zext/trunc/self of SCEVUnknown"" and it's follow-ups
While we haven't encountered an earth-shattering problem with this
Revert "Reland "[SCEV] Model ptrtoint(SCEVUnknown) cast not as unknown, but as zext/trunc/self of SCEVUnknown"" and it's follow-ups
While we haven't encountered an earth-shattering problem with this yet, by now it is pretty evident that trying to model the ptr->int cast implicitly leads to having to update every single place that assumed no such cast could be needed. That is of course the wrong approach.
Let's back this out, and re-attempt with some another approach, possibly one originally suggested by Eli Friedman in https://bugs.llvm.org/show_bug.cgi?id=46786#c20 which should hopefully spare us this pain and more.
This reverts commits 1fb610429308a7c29c5065f5cc35dcc3fd69c8b1, 7324616660fc0995fa8c166e3c392361222d5dbc, aaafe350bb65dfc24c2cdad4839059ac81899fbe, e92a8e0c743f83552fac37ecf21e625ba3a4b11e.
I've kept&improved the tests though.
show more ...
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
#
37b7922d |
| 14-May-2019 |
Kit Barton <kbarton@ca.ibm.com> |
Save the induction binary operator in IVDescriptors for non FP induction variables.
Summary: Currently InductionBinOps are only saved for FP induction variables, the PR extends it with non FP induct
Save the induction binary operator in IVDescriptors for non FP induction variables.
Summary: Currently InductionBinOps are only saved for FP induction variables, the PR extends it with non FP induction variable, so user of IVDescriptors can query the InductionBinOps for integer induction variables.
The changes in hasUnsafeAlgebra() and getUnsafeAlgebraInst() are required for the existing LIT test cases to pass. As described in the comment of the two functions, one of the requirement to return true is it is a FP induction variable. The checks was not needed because InductionBinOp was not set on non FP cases before.
https://reviews.llvm.org/D60565 depends on the patch.
Committed on behalf of @Whitney (Whitney Tsang).
Reviewers: jdoerfert, kbarton, fhahn, hfinkel, dmgreen, Meinersbur
Reviewed By: jdoerfert
Subscribers: mgorny, hiraditya, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61329
llvm-svn: 360671
show more ...
|