search for: getmatchingsuperregclass

Thanks! Our bug is now fixed. Our getMatchingSuperRegClass is huge (more than 300 lines), messy, and incomplete. > Or you could just rebase. On trunk, TableGen writes this difficult function for you. That in itself would be a compelling reason to get the rebase to trunk done. I just curious how large the generated version will be. :-) /Patrik Hägglun...

...<kill>; aN40_0_7:%vreg17 > aN32_0_7:%vreg4 > > The load instruction however, can only use registers from the rN class, > but the coalescer has changed so it now uses the lo16 part of a aN32 > register (which it cannot). When sub-registers are involved, the coalescer uses the getMatchingSuperRegClass hook to determine if the cross class join is possible, and what the resulting register class should be. In this case it would call getMatchingSuperRegClass(aN32_0_7, aNl_0_7, lo16) Check your implementation of that hook, and reread the comment describing what it does. It is quite tricky to get...

Hi, Is it intended that in some cases it is necessary to use "-disable-cross-class-join" to be sure the resulting code is ok? I have several cases where cross class joins are carried out that makes the code turn out illegal, because the "new" register class is not allowed in all instructions where it is now used. For example, by joining %vreg4, %vreg7 and %vreg9 the

...our example. I recommend: > 2. Insert COPY's, but these would not get coalesced away, so instead of saving instructions I ended up with one load and two moves...:-( How could I get the wide load to simply be used intelligently by COPYing to the old virtual registers? You need to implement getMatchingSuperRegClass in your register info class. That will give the coalescer the needed information to join subreg copies. /jakob

Hi, I am trying to take 16 bit memory reads and combine them to a single 32 bit read. I am having trouble to make the code simply read 32 bytes and the use the subregisters accordingly, without unnecessary copying. I have tried two techniques, in the MachineFunction: 1. replace the MachineOperands in the users of the data with the new register/subregister index. This yields an assert failure

On Mar 28, 2012, at 7:41 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > I'm facing a problem in my BE while trying to remove certain copies. > Here is a code snippet which I would like to optimize > > %vreg1<def> = READF32r; vRRegs:%vreg1 > %vreg2<def> = COPY %vreg1:rsub_h; iRSubRegs:%vreg2 vRRegs:%vreg1 > %vreg3<def> = COPY

Hi, I'm facing a problem in my BE while trying to remove certain copies. Here is a code snippet which I would like to optimize %vreg1<def> = READF32r; vRRegs:%vreg1 %vreg2<def> = COPY %vreg1:rsub_h; iRSubRegs:%vreg2 vRRegs:%vreg1 %vreg3<def> = COPY %vreg1:rsub_l; iRSubRegs:%vreg3 vRRegs:%vreg1 This code produces subreg-to-subreg copies but I would like to have direct

I'm looking at an issue where we want a particular pseudo-instruction to choose from a set of registers that is not included in the existing set of RegisterClass definitions. More concretely, there is a RegisterClass in ARMRegisterInfo.td defined as def rGPR : RegisterClass<"ARM", [i32], 32, (sub GPR, SP, PC)> { let AltOrders = [(add LR, rGPR), (trunc rGPR, 8)]; let

On Jun 21, 2011, at 10:20 AM, Jakob Stoklund Olesen wrote: > > On Jun 21, 2011, at 9:23 AM, Jim Grosbach wrote: > >> >> On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote: >> >>> In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well,

...p a disjoint coverage set (e.g. int regs, float regs, ...)? Some algorithms partition the problem this way. Initially, I just want the set of register classes to be closed under intersections and sub-register operations. That's what the coalescer needs. It is about having getCommonSubClass and getMatchingSuperRegClass return maximal results. Today, they sometimes return NULL or a class that is smaller than necessary. That doesn't give you a disjoint covering, you would need to close under set differences as well to get that. We could do that, but I think such a covering would be too fine-grained to be usefu...

On Jun 21, 2011, at 9:23 AM, Jim Grosbach wrote: > > On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote: > >> In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class. >> >> What