Sebastian Pop
2012-May-22 21:25 UTC
[LLVMdev] Predicate registers/condition codes question
Hi Eli, On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: >> Hey folks, >> >> We are having some difficulty with how we have been representing our >> predicate registers, and wanted some advice from the list. First, we >> had been representing our predicate registers as 1 bit (i1). The truth, >> however, is that they are 8 bits. The reason for this is that they >> serve as predicates for conditional execution of instructions, branch >> condition codes, and also as vector mask registers for conditional >> selection of vector elements. >> >> We have run into problems with type mismatches with intrinsics for some >> of our vector operations. We decided to try to solve it by representing >> the predicate registers as what they really are, namely i8. We changed >> our intrinsic and instruction definitions accordingly, changed the data >> type of the predicate registers to be i8, and changed >> getSetCCResultType() to return i8. After doing this, the compiler >> builds just fine but dies at runtime trying to match some target >> independent operations (e.g. setcc/brcond) that appear to want an i1 for >> the condition code. >> >> So, my question is this: is it even possible to represent our predicate >> registers (and our condition codes) as i8, and if so, what hook are we >> missing? > > Making getSetCCResultType return i8 is definitely supported, and > brcond should be okay with that. It's not obvious what is going > wrong; are you sure there isn't anything in your target still > expecting an i1?I have specified that Hexagon has an i8 predicate register that represents the true predicate as -1 with a sign extend like this: addRegisterClass(MVT::i8, &Hexagon::PredRegsRegClass); setBooleanContents(ZeroOrNegativeOneBooleanContent); and I'm calling this code just before computeRegisterProperties, that builds the TransformToType table specifying the type promotions: i1 -> i8 i8 -> i8 (legal) i16 -> i32 i32 -> i32 (legal) This would be fine if the register for i8 could be used for any integer operation (as in x86 for instance), but on Hexagon, predicate registers can only be used in a few logical operations. 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? Thanks, Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum PS: I have tried to tweak the TransformToType table to specify the type promotion i8 -> i32, by doing the following just after the call to computeRegisterProperties: RegisterTypeForVT[MVT::i8] = TransformToType[MVT::i8] = MVT::i32; and then legalize the SETCC on i8 and specify that for example the results of loads should be in i32 regs: setOperationAction(ISD::SETCC, MVT::i8, Legal); [...] setOperationAction(ISD::LOAD, MVT::i8, Promote); [...]
Hi Sebastian, On 22/05/2012 23:25, Sebastian Pop wrote:> Hi Eli, > > On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman<eli.friedman at gmail.com> wrote: >> On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum<tlinth at codeaurora.org> wrote: >>> Hey folks, >>> >>> We are having some difficulty with how we have been representing our >>> predicate registers, and wanted some advice from the list. First, we >>> had been representing our predicate registers as 1 bit (i1). The truth, >>> however, is that they are 8 bits. The reason for this is that they >>> serve as predicates for conditional execution of instructions, branch >>> condition codes, and also as vector mask registers for conditional >>> selection of vector elements. >>> >>> We have run into problems with type mismatches with intrinsics for some >>> of our vector operations. We decided to try to solve it by representing >>> the predicate registers as what they really are, namely i8. We changed >>> our intrinsic and instruction definitions accordingly, changed the data >>> type of the predicate registers to be i8, and changed >>> getSetCCResultType() to return i8. After doing this, the compiler >>> builds just fine but dies at runtime trying to match some target >>> independent operations (e.g. setcc/brcond) that appear to want an i1 for >>> the condition code. >>> >>> So, my question is this: is it even possible to represent our predicate >>> registers (and our condition codes) as i8, and if so, what hook are we >>> missing? >> >> Making getSetCCResultType return i8 is definitely supported, and >> brcond should be okay with that. It's not obvious what is going >> wrong; are you sure there isn't anything in your target still >> expecting an i1? > > I have specified that Hexagon has an i8 predicate register that > represents the true predicate as -1 with a sign extend like this: > > addRegisterClass(MVT::i8,&Hexagon::PredRegsRegClass); > setBooleanContents(ZeroOrNegativeOneBooleanContent); > > and I'm calling this code just before computeRegisterProperties, that > builds the TransformToType table specifying the type promotions: > > i1 -> i8 > i8 -> i8 (legal) > i16 -> i32 > i32 -> i32 (legal) > > This would be fine if the register for i8 could be used for any > integer operation (as in x86 for instance), but on Hexagon, predicate > registers can only be used in a few logical operations. > > 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. Ivan> > Thanks, > Sebastian > -- > Qualcomm Innovation Center, Inc is a member of Code Aurora Forum > > PS: I have tried to tweak the TransformToType table to specify the > type promotion i8 -> i32, by doing the following just after the call > to computeRegisterProperties: > > RegisterTypeForVT[MVT::i8] = TransformToType[MVT::i8] = MVT::i32; > > and then legalize the SETCC on i8 and specify that for example the > results of loads should be in i32 regs: > > setOperationAction(ISD::SETCC, MVT::i8, Legal); > [...] > setOperationAction(ISD::LOAD, MVT::i8, Promote); > [...] > > _______________________________________________ > 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-23 04:35 UTC
[LLVMdev] Predicate registers/condition codes question
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? Thanks, Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
Maybe Matching 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