[PATCH] Fix -ftree-ter -O0 (PR tree-optimization/43655)

[Richard Guenther]

On Wed, Dec 15, 2010 at 9:34 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Dec 15, 2010 at 03:26:52AM +0100, Richard Guenther wrote:
>> On Tue, Dec 14, 2010 at 2:56 PM, Jeff Law <law@redhat.com> wrote:
>> > I'm a little confused as to why TER is running when we're not optimizing.
>> >  There's no doubt more bugs of this nature lying around if we allow specific
>> > optimizers to be turned on at -O0.
>
> I think the reason we allow it is unit testing, plus, eventually we want
> some (limited) TER at -O0 for inline asm operands to get rid of the
> regressions tree-SSA and tuplification caused.
>
>> > If we're going to allow optimizers to run at -O0, wouldn't it be better to
>> > fix gimple_references_memory_p rather than have to twiddle each of its
>> > callers to DTRT at -O0.  At least one of the other users of
>> > gimple_references_memory_p seems to be prone to a similar bug
>> > (tree-tailcall.c).
>>
>> I originally wanted to get rid of gimple_references_memory_p.  For the specific
>> test is_gimple_val (rhs) is probably enough (given that we don't TER aggregate
>> copies).
>
> You mean
>  if (!optimized
>      && gimple_assign_single_p (stmt)
>      && !is_gimple_val (gimple_assign_rhs1 (stmt)))
>    return false;
> ?

Yes.

> As for the other uses of gimple_references_memory_p, I guess most if not all
> are never called for -O0, because neither gate_all_optimizations nor
> gate_all_early_optimizations allows most of the late tree passes (and early
> optimization passes) at all at -O0, no matter if they are enabled or not.
> That includes ccp, dom, loop opts, tail call/recursion which use that
> function.  And also pre, ealias and alias which use TODO_rebuild_alias.
> So I think tree-ter was the only -O0 user of that function.

Yep.  I think I converted most callers to gimple_reference_memory_p
to test gimple_vuse instead during alias-improvements merge but then
halfway decided that gimple_references_memory_p would be easier
to grok.  Well ;)

The patch is ok with the above change.

Thanks,
Richard.

>        Jakub
>