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.