This is triggered by the current version of D32278 when applied to trunk.
Details
Diff Detail
- Build Status
Buildable 6153 Build 6153: arc lint + arc unit
Event Timeline
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
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. |
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. |
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.