Tony Linthicum
2012-Feb-28 19:17 UTC
[LLVMdev] Predicate registers/condition codes question
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? Thanks in advance for any help you might be able to provide. Tony -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.
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? -Eli
Tony Linthicum
2012-Mar-06 22:43 UTC
[LLVMdev] Predicate registers/condition codes question
On 3/1/2012 2:21 PM, Eli Friedman 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? > > -EliThanks, Eli. We'll take another look at our target dependent information to see if some i1's are still lurking about. It's good to know that this should work. Tony -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.
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); [...]
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