This is an archive of the discontinued LLVM Phabricator instance.

[globalisel][tablegen] Fix nullptr dereferences when getVRegDef() is called on a phys reg.
Needs ReviewPublic

Authored by dsanders on May 4 2017, 9:44 AM.

Details

Summary

This is triggered by the current version of D32278 when applied to trunk.

Event Timeline

dsanders created this revision.May 4 2017, 9:44 AM
qcolombet edited edge metadata.May 11 2017, 2:45 PM

Hi Daniel,

I have trouble to relate the description of the patch and the patch itself.
I was expecting something that would generate some guard before getVRegDef and instead I see that we take the address instead of a reference to an instruction.
I am guessing this is because we want the code used to emit the matcher to work with either non-null or null instruction, but I fail to see this demonstrated in the patch. In other words, I don't see where we would have a nullptr dereferenced here.

Put differently, where does the getVRegDef come into play in that patch?

Cheers,
-Quentin

dsanders added inline comments.May 11 2017, 3:25 PM
test/TableGen/GlobalISelEmitter.td
141–142

There's only a couple of them in the test at the moment but here's one of the getVRegDef's.

getVRegDef() returns a pointer to the MI that def's the register or nullptr otherwise. Previously, we unconditionally dereferenced it which caused a nullptr dereference when the register was live-in but now we check for the nullptr first.

qcolombet added inline comments.May 12 2017, 1:59 PM
test/TableGen/GlobalISelEmitter.td
141–142

Here is it, I missed it with my previous search :).

I would rather have a check before the getVRegDef whether the register is a vreg or not.
I know getVRegDef works with PhysReg, but in practice we try not to call it on then, because it is strange :).