This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, Dec 14, 2010 at 2:56 PM, Jeff Law <law@redhat.com> wrote:
> On 12/14/10 02:41, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> In 4.4 gimple_references_memory_p checked a bit in the stmt, but starting
>> with 4.5 that inline just looks at vuses. ?Unfortunately, at -O0 there
>> are no vuses and thus is_replaceable_p at -O0 -ftree-ter happily moves
>> memory loads around.
>>
>> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
>> for
>> trunk?
>>
>> 2010-12-14 ?Jakub Jelinek<jakub@redhat.com>
>>
>> ? ? ? ?PR tree-optimization/43655
>> ? ? ? ?* tree-ssa-ter.c (is_replaceable_p): Don't use
>> ? ? ? ?gimple_references_memory_p for -O0, instead check for load
>> ? ? ? ?by looking at rhs.
>>
>> ? ? ? ?* g++.dg/opt/pr43655.C: New test.
>
> 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.
>
> 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).

Richard.

> Jeff
>
>
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]