Sebastian, First, it might be useful to look at what is done in the PowerPC backend. PPC also has condition registers that are larger than the 1-bit conditional results, and it defines 1-bit subregisters in addition to the larger condition registers. The spill-restore code ends up being more complicated, but that, perhaps, is a separate issue. [To be clear, I am not advocating for (or against) this solution even if it would work for you]. Second, generically speaking, the problem that you have seems much more general than the solution you propose. Correct me if I'm wrong, but your fundamental issue is that you have a type, i8, than can exist in different register classes, and the operations that are legal on that type depend on the current register class. The reason this is a problem is that legalization happens before register-class assignment. Currently, isTypeLegal does not take an opcode parameter, but maybe changing it to depend on the type of operation (like getTypeToPromoteTo does) and the opcode of the node's inputs would help? -Hal On Thu, 24 May 2012 16:11:30 -0500 Sebastian Pop <spop at codeaurora.org> wrote:> Hi, > > On Tue, May 22, 2012 at 11:35 PM, Sebastian Pop <spop at codeaurora.org> > wrote: > > Hi Ivan, > > > > On Tue, May 22, 2012 at 5:09 PM, Ivan Llopard > > <ivanllopard at gmail.com> wrote: > >> Hi Sebastian, > >> > >> On 22/05/2012 23:25, Sebastian Pop wrote: > >>> So my question is how do we specify that for most of the > >>> operations i8 should be promoted to i32 and that only a few > >>> logical operations are legal on i8? > >> > >> I think the combo TargetLowerInfo::isTypeDesirableForOp() and > >> IsDesirableToPromoteOp() may help you here. X86 does something > >> similar. > > > > I just tried these functions, and it seems like they are only > > modifying the behavior of type promotions for a small subset of > > operations (PromoteIntBinOp, PromoteIntShiftOp, PromoteExtend, > > PromoteLoad, SimplifyBinOpWithSameOpcodeHands, visitSRL, > > visitTRUNCATE that matter to the performance of i16 on X86.) > > > > I don't like the "desirable" in the name of these functions: in the > > case of Hexagon it is illegal to use an i8 predicate register for > > anything else than setcc, brcond, and the logical ops: so doing the > > conversion is a matter of correctness, not of desirability. > > > > Should I add a call to IsDesirableToPromoteOp in every other > > operation that is currently missing this check for type promotion, > > or do we want a new hook? > > I found it pretty difficult to modify the existing DAG combiner to > add the missing calls to isDesirableToPromoteOp, so I abandoned this > path. > > I found it easier to work with a new integer type p8 for the 8 bit > predicates, such that I can promote i1 into p8 and avoid the confusion > of integer and predicate registers that I had when using the same i8 > type. > > Would a patch adding the p8 type be ok to commit to llvm? > > Thanks, > Sebastian > -- > Qualcomm Innovation Center, Inc is a member of Code Aurora Forum > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
Sebastian Pop
2012-May-24 22:40 UTC
[LLVMdev] Predicate registers/condition codes question
On Thu, May 24, 2012 at 5:06 PM, Hal Finkel <hfinkel at anl.gov> wrote:> Sebastian, > > First, it might be useful to look at what is done in the PowerPC > backend. PPC also has condition registers that are larger than the > 1-bit conditional results, and it defines 1-bit subregisters in > addition to the larger condition registers. The spill-restore code ends > up being more complicated, but that, perhaps, is a separate issue. [To > be clear, I am not advocating for (or against) this solution even if it > would work for you].Ok, thanks for the pointer, I'll go read in the PPC bits.> Second, generically speaking, the problem that you > have seems much more general than the solution you propose. Correct > me if I'm wrong, but your fundamental issue is that you have a type, i8, > than can exist in different register classes, and the operations that > are legal on that type depend on the current register class. The reason > this is a problem is that legalization happens before register-class > assignment.Yes, that's correct.> Currently, isTypeLegal does not take an opcode parameter, but maybe > changing it to depend on the type of operation (like getTypeToPromoteTo > does) and the opcode of the node's inputs would help?I will try to see if I can fix isTypeLegal. Thanks for your helpful comments. Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
On 25/05/2012 00:40, Sebastian Pop wrote:> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov> wrote: >> Sebastian, >> >> First, it might be useful to look at what is done in the PowerPC >> backend. PPC also has condition registers that are larger than the >> 1-bit conditional results, and it defines 1-bit subregisters in >> addition to the larger condition registers. The spill-restore code ends >> up being more complicated, but that, perhaps, is a separate issue. [To >> be clear, I am not advocating for (or against) this solution even if it >> would work for you]. > > Ok, thanks for the pointer, I'll go read in the PPC bits. > >> Second, generically speaking, the problem that you >> have seems much more general than the solution you propose. Correct >> me if I'm wrong, but your fundamental issue is that you have a type, i8, >> than can exist in different register classes, and the operations that >> are legal on that type depend on the current register class. The reason >> this is a problem is that legalization happens before register-class >> assignment. > > Yes, that's correct. > >> Currently, isTypeLegal does not take an opcode parameter, but maybe >> changing it to depend on the type of operation (like getTypeToPromoteTo >> does) and the opcode of the node's inputs would help? > > I will try to see if I can fix isTypeLegal. > Thanks for your helpful comments.Just an idea, you may know that it's possible to custom expand operations with illegal types and it might be useful in this case (considering i1 as illegal). The TypeLegalizer will callback to your lowering function at the very beginning of the Combining/Legalization phases. If you add HexagonISD nodes in the process while promoting operands/result, you will be able to precisely match them later with its associated regclass (PReg?). Unfortunately, it will not resolve your problem with non-allowed ops for i8 types and I think I'm missing something regarding this matter. Why don't you mark for promotion everything but logical ops ? Are copies between pred regs and IntRegs not allowed ? Ivan> > Sebastian > -- > Qualcomm Innovation Center, Inc is a member of Code Aurora Forum > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Sebastian Pop
2012-May-25 16:54 UTC
[LLVMdev] Predicate registers/condition codes question
On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop <spop at codeaurora.org> wrote:> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> Sebastian, >> >> First, it might be useful to look at what is done in the PowerPC >> backend. PPC also has condition registers that are larger than the >> 1-bit conditional results, and it defines 1-bit subregisters in >> addition to the larger condition registers. The spill-restore code ends >> up being more complicated, but that, perhaps, is a separate issue. [To >> be clear, I am not advocating for (or against) this solution even if it >> would work for you]. > > Ok, thanks for the pointer, I'll go read in the PPC bits.I see that PPC has its condition registers CRRC as i32, and that PPC also has general purpose i32 registers GPRC, so the situation is slightly different than on Hexagon, where there are no general purpose registers of the same size as the predicate registers: i8. So on PPC it is "safe" to promote from i1 to i32 and to "allow confusion" between the promoted i32 and the existing operations that were using i32: as we can always select between a CR and a GPR following the op type. On Hexagon, if type legalization promotes i1 into i8, that would create this confusion between the i8 ops existing before legalization and the newly promoted ones. Then as Ivan was suggesting, we will have to provide custom expansion to promote the "illegal" ops on i8 on almost all the operations, except logical ops. Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
Reasonably Related Threads
- [LLVMdev] Predicate registers/condition codes question
- [LLVMdev] Predicate registers/condition codes question
- [LLVMdev] Predicate registers/condition codes question
- [LLVMdev] Predicate registers/condition codes question
- [LLVMdev] Predicate registers/condition codes question