when coercing loads, it inserts some instructions, which have no GV assigned.
Details
Diff Detail
Event Timeline
This patch doesn't make sense.
Either you need to have it assign the GV and fix the leader tables so that
the lookup at this point succeeds (which is ideal), or VN.lookup(op) ==
null, it should set success=false and break.
The former is *greatly* preferable to the latter.
What you've done here makes no sense, because findLeader(anything, <new
value number>) will always return nothing, since addLeaderToTable has not
been called on the new value number.
All you are doing in that case is wasting time calling findLeader.
This patch is just for review purpose. It only handles the cases in GetLoadValueForLoad().
If the fix is right, I can apply it to other routines like CoerceAvailableValueToLoadType
lib/Transforms/Scalar/GVN.cpp | ||
---|---|---|
646 | Close, but if you are adding only the new instructions, I believe this should be unconditional. Think of the leader table as "the list of things in the program that have a given value number". Even if the value number existed, if this is a new instruction, it's still a new thing that has that value number, and should still end up in the leader table. (I'd also probably name it addNewInstruction or something) | |
1231 | These definitely look right |
lib/Transforms/Scalar/GVN.cpp | ||
---|---|---|
646 | Is it possible that the new instruction has some existing GVN ? I was thinking calling processInstruction, but concerned that it may have side effect. |
lib/Transforms/Scalar/GVN.cpp | ||
---|---|---|
646 | It is possible the new instruction has an existing VN. Imagine instruction is the lshr you have below, of a constant and a value. Imagine we coerce a bunch of loads. We are highly likely to insert the lshr a bunch of times, and it will be the same each time. It happens that the current VN is not great, and so it won't find stuff unless they are pretty much completely identical. processInstruction does a lot of forward propagation to try to make things look the same to account for this. You also can't call processInstruction here because it may mess with or delete things or change the CFG or ... (One of the other nice things new gvn does is split analysis and elimination, so that would never happen. It would be hard to fix this in existing GVN) So i think what you are doing here is pretty much the best you can do in this situation, it should probably just be unconditional, as i mentioned. |
lib/Transforms/Scalar/GVN.cpp | ||
---|---|---|
646 | Cool. Thanks for the detailed explanation. |
LGTM
It would be super nice to have testcases for all of these, but i suspect that would be pretty hard to test by hand.
I wonder if it doesn't make sense to have, at the end of GVN:
#ifdef DEBUG
for each instruction
assert that VN.lookup returns a non-null value
#endif
to make sure we catch all the cases this can happen in.
Because i suspect it happens in loadpre as well, when phitranslate inserts instructions, etc.
Close, but if you are adding only the new instructions, I believe this should be unconditional.
Think of the leader table as "the list of things in the program that have a given value number".
Even if the value number existed, if this is a new instruction, it's still a new thing that has that value number, and should still end up in the leader table.
(I'd also probably name it addNewInstruction or something)