Variable register class using HwMode
Needs ReviewPublic

Authored by abeserminji on Feb 14 2018, 4:52 AM.

Details

Summary

This patch introduces RegClassByHwMode which allows choosing the certain register class in run-time, depending on activated features.

For example:

def HwModeA  : HwMode<"+fp64", "RegClass">;
def VarRegClass : RegisterClassByHwMode<[DefaultMode, HwModeA], [DefaultRegClass, FP64RegClass]>,  RegisterClass<"Target", [f64], 64, (add D0)>;

When +fp64 feature is present, HwModeA is active and VarRegClass behaves like FP64RegClass. Otherwise it becomes DefaultRegClass.

Concern that I have here is that VarRegClass has to inherit RegisterClass in order to use it for instruction definitions. RegisterClass as defined in this case is not used later, because it's substituted with DefaultRegClass/FP64RegClass in tables like MCRegisterClasses[], RegisterClasses[] etc. I'd be glad to hear some comments on that/suggestions on how to fix it.

Depends on D43238. This is second in a series of three patches.

Diff Detail

abeserminji created this revision.Feb 14 2018, 4:52 AM

What is the exact difference between DefaultRegClass and FP64RegClass? TableGen precalculates certain properties of register classes that must be preserved, (such as class ordering).

In my particular example for Mips I have a situation like this:

def AFGR64 : RegisterClass<"Mips", [f64], 64, (sequence "D%u", 0, 15)>;
def FGR64 : RegisterClass<"Mips", [f64], 64, (sequence "D%u_64", 0, 31)>;
def VarFGR64 : RegisterClassByHwMode<[DefaultMode, HwMips64], [AFGR64, FGR64]>, RegisterClass<"Mips", [f64], 64, (add D0)>;

Where AFGR64 and FGR64 would represent DefaultRegClass and FP64RegClass.
Until now I didn't experience any problems with wrong offsets being calculated, but maybe I'm missing something here?

Changing class members may affect topological ordering (see TopoOrderRC). This is something that TableGen precomputes and that cannot be changed at runtime without repeating all this computation.