This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Copy prop into virtual operands
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Andrew Macleod <amacleod at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 29 Jul 2003 09:35:04 -0600
- Subject: Re: [tree-ssa] Copy prop into virtual operands
- Reply-to: law at redhat dot com
In message <1059492530.3164.54.camel@frodo.toronto.redhat.com>, Diego Novillo w
rites:
>On Tue, 2003-07-29 at 11:25, law@redhat.com wrote:
>> In message <1059491832.3164.36.camel@frodo.toronto.redhat.com>, Diego Novil
>lo w
>> rites:
>> >On Tue, 2003-07-29 at 11:14, Andrew MacLeod wrote:
>> >
>> >> > Right. But I don't see how we would get into this situation. After
>> >> > all, we only do constant propagation on real operands.
>> >> >
>> >> How do you know what a real operand is now? you don't have a flag any
>> >> more...
>> >>
>> >CCP only propagates from def_ops() into use_ops(). We only follow
>> >use-def chains on real operands, not virtual. And any definition coming
>> >from anything but the LHS of a MODIFY_EXPR is considered VARYING.
>> This is not in CCP. This is in the dominator optimizer. If you wait
>> until CCP, then you'll get little/no benefit from propagating into
>> virtual operands.
>>
>Similar principle, the dominator optimizers don't pick up constant
>values from VDEFs, do they? If 'a' is aliased:
>
> a_2 = VDEF <a_1>
> a = 3;
>
>we won't register the tuple <a_2, '3'> in const_and_copies, correct?
It shouldn't.
This whole discussion is about a subtle point which I wasn't even sure
could actually happen, it was a "what if..." scenario. If it can't happen,
then we should be able to remove that check, or turn it into an
ENABLE_CHECKING abort.
jeff