search for: thumb2instrinfo

...o various RegisterClass definitions (like GPR pairs just for R0-R7, another for rGPR that doesn't contain the SP, .). If I add a new RegisterClass however, the dynamically created GPRPair class corresponding to this new RegisterClass overlaps with the dynamically created class for rGPR. In Thumb2InstrInfo.cpp, the dynamically created TargetRegisterClass GPRPair_with_gsub_1_in_rGPRRegClass is explicitly called out. If I add my new class, the class GPRPair_with_gsub_1_in_rGPRRegClass is never created, instead the class GPRPair_with_gsub_1_in_newGPRRegClass is created. Compilation therefore fails. I co...

...but does work except in this case of load/store haflword and byte to stack objects. >> > > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. > > If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. > >> Maybe I'm shooting myself in the foot there. I don't know that code...

...of awkward but does work except in this case of load/store haflword and byte to stack objects. > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. > Maybe I'm shooting myself in the foot there. I don't know that code too well so mayb...

...except in this case of load/store haflword and byte to stack objects. >>> >> >> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. >> >> If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. >> >>> Maybe I'm shooting myself in the foot there. I don...

Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are

...this case of load/store haflword and byte to stack objects. >>>> >>> >>> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. >>> >>> If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. >>> >>>> Maybe I'm shooting myself in the foot t...

...ead-only TableGen'd tables and switch blocks encoding the various classes, subclasses, and their relationships. The approach I had taken in my patch was to include ARMGenInstrInfo.inc for a second time, after re-defining rGPRRegClassID to use a different RegClass in the same instructions. Then, Thumb2InstrInfo constructor overrides the MCInstrInfo that it inherited from ARMBaseInstrInfo with the "patched" one. (This "patching", still, happens at compile-time.) As John rightly noted, this approach looks rather hacky and confusing: This isn't "rGPR includes SP" it&...