[LLVMdev] Registers and isel type inference

Jakob Stoklund Olesen stoklund at 2pi.dk
Fri Sep 23 16:22:49 PDT 2011

On Sep 23, 2011, at 1:38 PM, David A. Greene wrote:

> Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:
>> It appears that tablegen is inferring the 'type' of an individual
>> register by enumerating all the register classes it appears in.  Some
>> things, like using implicit defs in SDNodes, only works for registers
>> with a unique type.  My WIDE32 class caused GR32 registers to no
>> longer have a unique type, breaking the world.
> I can't remeber the specific situation, but I remember running into
> this kind of problem before.
>> This seems too fragile to me. 
> Yes, it is.  :(
>> - Disable type inference for individual registers entirely, or
>> - Add a ValueType field to the Register tablegen class, so types are
>>  not inferred by enumerating register classes.
> I tend to think the second would be preferable, but how would we handle
> registers than can hold different types of values?

AFAIK, the type inference is only a convenience, you can always use explicit casts to get at the other types.

It's the use of HasOneImplicitDefWithKnownVT() that scares me, I don't think there is any workaround for that.


/// HasOneImplicitDefWithKnownVT - If the instruction has at least one
/// implicit def and it has a known VT, return the VT, otherwise return
/// MVT::Other.
MVT::SimpleValueType CodeGenInstruction::
HasOneImplicitDefWithKnownVT(const CodeGenTarget &TargetInfo) const {
  if (ImplicitDefs.empty()) return MVT::Other;

  // Check to see if the first implicit def has a resolvable type.
  Record *FirstImplicitDef = ImplicitDefs[0];
  const std::vector<MVT::SimpleValueType> &RegVTs =
  if (RegVTs.size() == 1)
    return RegVTs[0];
  return MVT::Other;

More information about the llvm-dev mailing list