Ok.
Regarding this particular patch, I hope it can be checked in to make
the test clean. It is a simple enhancement to a wheel that is already
there. It also serves as a case that can be referenced in the future
when the more general mechanism is available.
Thanks,
David
On Wed, Mar 9, 2011 at 9:54 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> On Wed, Mar 9, 2011 at 6:34 PM, Xinliang David Li <davi...@google.com> wrote:
>> On Wed, Mar 9, 2011 at 8:29 AM, Richard Guenther
>> <richard.guent...@gmail.com> wrote:
>>> On Wed, Mar 9, 2011 at 5:24 PM, Xinliang David Li <davi...@google.com>
>>> wrote:
>>>> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law <l...@redhat.com> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 03/09/11 02:45, Richard Guenther wrote:
>>>>>> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law <l...@redhat.com> wrote:
>>>>>
>>>>>> True. I've been repeatedly thinking of building some on-the-side CFG
>>>>>> with value-numbered predicates to also catch the CFG vs. scalar-code
>>>>>> predicate combinations we have. On such on-the-side data structure
>>>>>> we could do very aggressive jump-threading just for analysis purposes
>>>>>> (experiments when working on separating conditions shows that
>>>>>> a PRE-like algorithm could drive this).
>>>>> I'm pondering the same kind of thing. PRE on the predicates with a more
>>>>> structured approach to block copying to isolate the paths seems to be
>>>>> the way to go.
>>>>
>>>>
>>>> Any simple examples to show how your idea would work?
>>>
>>> You basically would copy all paths with redundant predicate computations,
>>> removing them and leaving no redundant checks around. Of course you
>>> wouldn't really do this code-transformation but just do it to help analyses.
>>
>> You will also need to compute SSA on the alternate CFG as well, right?
>
> It depends on what task you want to perform on the alternate CFG. For
> uninitialized vars, yes, likely.
>
>> How will partially redundant predicates handled? Split the predicates?
>
> Yes.
>
>> if (p1 OR p2)
>> foo();
>> bar();
>> if (p1)
>> baz();
>>
>> ==>
>>
>> if (p1)
>> {
>> foo(); bar(); baz();
>> }
>> else if (p2)
>> {
>> foo(); bar();
>> }
>> else
>> bar();
>>
>> Things can be complicated when dealing with slightly complex
>> predicates. For instance
>>
>> p1 = x | y; // bitwise OR
>>
>> p2_1 = (x!=0);
>> p2_2 = (y!=0);
>> p2 = (p2_1 & p2_2);
>>
>> p1 can be split into (x AND !y), p2 , and (!x AND y).
>>
>> How about short circuite &&, || expressions lowered into if-then-else?
>> Will the side CFG collapse the expanded branches and expose the
>> 'original' predicates that are easier to analyze?
>
> That all remains to be seen. Just the current restriction of working on
> the present IL for analysis purposes should be lifted (and made easier
> w/o the need to re-invent the wheel everywhere).
>
> Richard.
>
>> Thanks,
>>
>> David
>>
>>
>>>
>>> Like in
>>>
>>> if (p)
>>> foo();
>>> bar();
>>> if (p)
>>> baz();
>>>
>>> you'd generate
>>>
>>> if(p)
>>> {
>>> foo();
>>> bar();
>>> baz();
>>> }
>>> else
>>> bar();
>>>
>>> for all, even partially redundant predicates. See the patch I linked to, it
>>> causes PRE to identify them (but do nothing too useful yet)
>>>
>>> Richard.
>>>
>>>> Thanks,
>>>>
>>>> David
>>>>>
>>>>> jeff
>>>>>
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>>>>>
>>>>> iQEcBAEBAgAGBQJNd4irAAoJEBRtltQi2kC73SAH/jIC30j/CkWSV9rQGYn+gtfD
>>>>> WiBXnbYxv7rc6PUqkT8U5I3upk/subJKlAhAQ1D1Eg6355QqpcMh7yZJGz20ovGc
>>>>> CXQOK1ZbtCXvk6uZ8QamdfowojhkkxQo900c9mJtuaaevjywwt+MX3VwShNIrfbA
>>>>> bKSIjHVeeZ2qwymNYHV8C82Zss5WA72FQqIpmlTlPKEwWFO49jLld/iXszyjC1cF
>>>>> OWQdH37ZNgXARibaWI28KZCz5B39yz5F4mljVCyMS9XvNKzfwabT5FHj8btYzdAK
>>>>> HYoAsBtONN/0/FJPn3I9VwyYC0q8M6tm9BgMyhhVmCU2PWMCt0jZJZA9aW/4X+o=
>>>>> =R64B
>>>>> -----END PGP SIGNATURE-----
>>>>>
>>>>
>>>
>>
>
