Revision tags: 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 |
|
#
b482e1bf |
| 23-Jan-2020 |
Jay Foad <jay.foad@amd.com> |
[CodeGen] Make use of MachineInstrBuilder::getReg
Reviewers: arsenm
Subscribers: wdng, hiraditya, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73262
|
Revision tags: 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 |
|
#
e9a57c2b |
| 09-Aug-2019 |
Daniel Sanders <daniel_l_sanders@apple.com> |
[globalisel] Add G_SEXT_INREG
Summary: Targets often have instructions that can sign-extend certain cases faster than the equivalent shift-left/arithmetic-shift-right. Such cases can be identified b
[globalisel] Add G_SEXT_INREG
Summary: Targets often have instructions that can sign-extend certain cases faster than the equivalent shift-left/arithmetic-shift-right. Such cases can be identified by matching a shift-left/shift-right pair but there are some issues with this in the context of combines. For example, suppose you can sign-extend 8-bit up to 32-bit with a target extend instruction. %1:_(s32) = G_SHL %0:_(s32), i32 24 # (I've inlined the G_CONSTANT for brevity) %2:_(s32) = G_ASHR %1:_(s32), i32 24 %3:_(s32) = G_ASHR %2:_(s32), i32 1 would reasonably combine to: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 25 which no longer matches the special case. If your shifts and extend are equal cost, this would break even as a pair of shifts but if your shift is more expensive than the extend then it's cheaper as: %2:_(s32) = G_SEXT_INREG %0:_(s32), i32 8 %3:_(s32) = G_ASHR %2:_(s32), i32 1 It's possible to match the shift-pair in ISel and emit an extend and ashr. However, this is far from the only way to break this shift pair and make it hard to match the extends. Another example is that with the right known-zeros, this: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 24 %3:_(s32) = G_MUL %2:_(s32), i32 2 can become: %1:_(s32) = G_SHL %0:_(s32), i32 24 %2:_(s32) = G_ASHR %1:_(s32), i32 23
All upstream targets have been configured to lower it to the current G_SHL,G_ASHR pair but will likely want to make it legal in some cases to handle their faster cases.
To follow-up: Provide a way to legalize based on the constant. At the moment, I'm thinking that the best way to achieve this is to provide the MI in LegalityQuery but that opens the door to breaking core principles of the legalizer (legality is not context sensitive). That said, it's worth noting that looking at other instructions and acting on that information doesn't violate this principle in itself. It's only a violation if, at the end of legalization, a pass that checks legality without being able to see the context would say an instruction might not be legal. That's a fairly subtle distinction so to give a concrete example, saying %2 in: %1 = G_CONSTANT 16 %2 = G_SEXT_INREG %0, %1 is legal is in violation of that principle if the legality of %2 depends on %1 being constant and/or being 16. However, legalizing to either: %2 = G_SEXT_INREG %0, 16 or: %1 = G_CONSTANT 16 %2:_(s32) = G_SHL %0, %1 %3:_(s32) = G_ASHR %2, %1 depending on whether %1 is constant and 16 does not violate that principle since both outputs are genuinely legal.
Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, arsenm
Subscribers: sdardis, jvesely, wdng, nhaehnle, rovka, kristof.beyls, javed.absar, hiraditya, jrtc27, atanasyan, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61289
llvm-svn: 368487
show more ...
|
Revision tags: 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, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3 |
|
#
8bc57953 |
| 08-Feb-2019 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
Re-apply r353553 "[GISel][NFC]: Add missing call to record CSE hits in the CSEMIRBuilder"
With a fix after r353563 that adds some more opcodes.
llvm-svn: 353579
|
#
decba8aa |
| 08-Feb-2019 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
Revert r353553 "[GISel][NFC]: Add missing call to record CSE hits in the CSEMIRBuilder"
This reverts commit r353553.
This breaks CodeGen/AArch64/GlobalISel/legalize-ext-csedebug-output.mir:
http:/
Revert r353553 "[GISel][NFC]: Add missing call to record CSE hits in the CSEMIRBuilder"
This reverts commit r353553.
This breaks CodeGen/AArch64/GlobalISel/legalize-ext-csedebug-output.mir:
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/57963/console
llvm-svn: 353575
show more ...
|
Revision tags: llvmorg-7.1.0, llvmorg-7.1.0-rc1 |
|
#
01e818a9 |
| 08-Feb-2019 |
Aditya Nandakumar <aditya_nandakumar@apple.com> |
[GISel][NFC]: Add missing call to record CSE hits in the CSEMIRBuilder
https://reviews.llvm.org/D57932
Add some logging + tests to make sure CSEInfo prints debug output.
reviewed by: arsenm
llvm-
[GISel][NFC]: Add missing call to record CSE hits in the CSEMIRBuilder
https://reviews.llvm.org/D57932
Add some logging + tests to make sure CSEInfo prints debug output.
reviewed by: arsenm
llvm-svn: 353553
show more ...
|
Revision tags: llvmorg-8.0.0-rc2 |
|
#
8121ec26 |
| 04-Feb-2019 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
GlobalISel: Fix CSE handling of buildConstant
This fixes two problems with CSE done in buildConstant. First, this would hit an assert when used with a vector result type. Solve this by allowing CSE
GlobalISel: Fix CSE handling of buildConstant
This fixes two problems with CSE done in buildConstant. First, this would hit an assert when used with a vector result type. Solve this by allowing CSE on the vector elements, but not on the result vector for now.
Second, this was also performing the CSE based on the input ConstantInt pointer. The underlying buildConstant could potentially convert the constant depending on the result type, giving in a different ConstantInt*. Stop allowing the APInt and ConstantInt forms from automatically casting to the result type to avoid any similar problems in the future.
llvm-svn: 353077
show more ...
|
Revision tags: llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
#
500e3ead |
| 16-Jan-2019 |
Aditya Nandakumar <aditya_nandakumar@apple.com> |
[GISel]: Add support for CSEing continuously during GISel passes.
https://reviews.llvm.org/D52803
This patch adds support to continuously CSE instructions during each of the GISel passes. It consis
[GISel]: Add support for CSEing continuously during GISel passes.
https://reviews.llvm.org/D52803
This patch adds support to continuously CSE instructions during each of the GISel passes. It consists of a GISelCSEInfo analysis pass that can be used by the CSEMIRBuilder.
llvm-svn: 351283
show more ...
|