I have a question about PromoteMem2Reg::RewriteSingleStoreAlloca.
Specifically, this bit of code:
// If the store dominates the block and if we haven't processed it yet,
// do so now. We can't handle the case where the store doesn't
dominate a
// block because there may be a path between the store and the use, but we
// may need to insert phi nodes to handle dominance properly.
if (!StoringGlobalVal && !dominates(OnlyStore->getParent(),
UseBlock))
continue;
This prevents mem2reg from forwarding the single store to uses that
it does not dominate. Why is this only prevented when NOT storing
to global values? I would think it would be exactly the opposite. A global
value may have some value coming into the Function so I don't see how
mem2reg can forward store values that don't dominate uses. On the
other hand, local values that have a use not dominated by the store means
there's a potential use-before-def, the program is invalid, and the compiler
is free to do whatever it wants (assuming this is what the language semantics
say).
The condition above looks exactly opposite of what we want.
Thoughts?
-Dave
On Fri, Sep 19, 2008 at 11:08 AM, David Greene <dag at cray.com> wrote:> \Why is this only prevented when NOT storing > to global values?It's not a question of storing *to* a global value, but storing a global value into the alloca. If there's only a single store to an alloca, there are only two possible values that can be extracted from the alloca: the value stored, and undef. Assuming it's well-defined, it's always correct to use the value stored, because undef can be anything. The reason for the check is question is that the stored value might not dominate the use. This is only possible, however, if the stored value is an instruction; dominance doesn't make sense if StoringGlobalVal is true. -Eli
On Friday 19 September 2008 17:17, Eli Friedman wrote:> On Fri, Sep 19, 2008 at 11:08 AM, David Greene <dag at cray.com> wrote: > > \Why is this only prevented when NOT storing > > to global values? > > It's not a question of storing *to* a global value, but storing a > global value into the alloca. If there's only a single store to anAh, ok.> alloca, there are only two possible values that can be extracted from > the alloca: the value stored, and undef. Assuming it's well-defined, > it's always correct to use the value stored, because undef can be > anything.I agree.> The reason for the check is question is that the stored value might > not dominate the use. This is only possible, however, if the storedYes, that's the case I am seeing.> value is an instruction; dominance doesn't make sense if > StoringGlobalVal is true.Ok, so you're saying that because we're storing a global value, by definition it DOES dominate the use because it's a global (and thus live-in to the Function). Is that right? In the case I'm seeing, the "global value" is a constant. So I guess it's ok to forward that constant value to the use even though the store does not dominate it (as you say, undef can be anything). All right, this makes sense to me. But why is it any different if the stored value is from an instruction? We're storiung some value into an alloca (under a condition in this case) and the alloca later gets used in a place not dominated by the store (outside the condition in this case). Who cares where the value being stored came from? -Dave