This is the mail archive of the
mailing list for the GCC project.
On 7/27/10 10:07 PM, Jeff Law wrote:
On 07/19/10 12:39, Maxim Kuvyrkov wrote:
While that's technically correct, I see hoist_expr_reaches_here_p as
designed to perform it's job using antloc, transp, and other data
sets, i.e., without examining the instruction stream. It seems simpler
to handle corner cases like this one by cleaning up the data sets
earlier in the pass.
But you don't know the target block for the insertion when you're
pruning the data sets. Thus you don't know if the target block has any
of the odd situations which require insertion earlier in the block.
I think the fact that there is an "odd" instruction on the path from
expression's initial location to the target makes it impossible to hoist
it to the target block. Even if the target block is "normal" and
instructions can be added immediately at its end the "odd" instruction
will clobber the expression.
hoist_expr_reaches_here_p is supposed to determine if an expression, if
inserted at the "end" of a specific block reaches a later point in the
cfg unchanged. Since we know the target block of the insertion we can
check for the various odd conditions that require insertion before the
actual end of the target block.
In general, I agree. I just cannot readily come up with a case that
would be under-optimized by pruning data sets compared to
hoist_expr_reaches_here_p. Anyway, that's, probably, moot at this point.
I think at this point we should go forward with your patch and if you
could add a pair of comments to expr_reaches_here_p and the pruning code
which touch on the problems with set-and-jump insns as a separate patch,
that would be greatly appreciated.
Thanks for review!
(650) 331-3385 x724