On Wed, Jul 31, 2013 at 11:08 PM, Steve Reinhardt <[email protected]> wrote:
> > I suspect x86 regressions would fail. In operands.isa we explicitly set >> the index for each register. >> > > You're right, I made the change and the x86 O3 regressions are the only > ones that fail. I don't get why though, as the indices in operands.isa > don't seem that well aligned with the constants in arch/x86/registers.hh. > For example, the control regs in operands.isa seem to start at 100, while > Ctrl_Base_DepTag is the result of a complex equation that happens to work > out to 184. > I did figure this out (at least partially)... there's this IntFoldBit which is 1<<6 (i.e., 64) that gets ORed in to the register index in some situations (not clear why, seems to have to do with byte-size reg accesses). So even though NumIntRegs is smaller, FP_Base_DepTag has to be 128 in order for it to be above any int reg even when it has that IntFoldBit set. That still doesn't explain why sometimes FP reg indices are offset by FP_Base_DepTag and other times by NumIntRegs, though. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
