search for: hasoneimplicitdefwithknownvt

...numerating 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. /jakob /// 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:: HasOneImplicitDefW...

...eferable, 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. True. Wouldn't that also work for implicit defs? > It's the use of HasOneImplicitDefWithKnownVT() that scares me, I don't > think there is any workaround for that. Can you explain more? I'm not quiet following. What workaround is needed? Are you saying that in the current system it's broken because it relies on a single type for a register or that replacing it with somethin...

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

So I tried adding a new register class to the x86 target: def WIDE32 : RegisterClass<"X86", [i32, f32], 32, (add GR32, FR32)>; I thought this would be a harmless thing to do since the new register class is not being referenced anywhere. I was wrong, it caused all kinds of assertion failures from tablegen's isel pattern generator. It appears that tablegen is inferring the

...The implicit defs don't participate much in the patterns. For the most part it's just read into CodeGenInstruction::ImplicitDefs and then GlobalISel gathers and adds them all at the end. I think I do see the code Gabriel is referring to though. GetNumNodeResults() has: if (InstInfo.HasOneImplicitDefWithKnownVT(CDP.getTargetInfo()) !=MVT::Other) ++NumDefsToAdd; and ultimately this VT gets into Types via UpdateNodeType(). I have no idea why this code does this as I don't really see why the VT matters to how you treat an implicit def. This code dates back to 2010 (r99726) and that commit called...

Hi, I'm trying to revive jacobly0's Z80 back-end (from https://github.com/jacobly0/llvm-z80) and build it with a current version of LLVM. Apart from some interface changes, I'm stuck at building the tables. Specifically, the generation of the DAG instruction selector causes an assertion in the table generator: Assertion failed: Ops.size() >= NumSrcResults &&