fix for pr47837

Xinliang David Li davidxl@google.com
Wed Mar 9 16:29:00 GMT 2011


Sounds interesting. Do you have examples to illustrate your idea?

Thanks,

David

On Wed, Mar 9, 2011 at 1:45 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law <law@redhat.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/08/11 11:55, Diego Novillo wrote:
>>> On 03/08/2011 12:54 PM, Xinliang David Li wrote:
>>>> Please review the attached patch, it does some simplification of the
>>>> complicated logical or expressions (x1 or x2 or x3 ...) constructed
>>>> from control flow analysis into simpler form.
>>>>
>>>> Bootstraps and works on s390x for both testcases.
>>>>
>>>> Bootstraps on x86-64. Regression testing is on going (it takes forever
>>>> (whole night already) to finish possibly because the lto test in
>>>> c-torture ..).
>>>>
>>>> Ok for trunk?
>>>
>>> As a general comment, do you think we will start adding more and more of
>>> these special pattern matchers into uninit analysis?  I'm wondering how
>>> much effort should we make into creating something more generic.
>>>
>>> Right now it's this pattern, but there may be others.  It could grow
>>> pretty big and ugly.
>> We have a real problem in that our underlying analysis to eliminate
>> unexecutable edges is the CFG needs help, particularly for path
>> sensitive cases.
>>
>> Given that I'm seeing a real interest in other analysis that ultimately
>> have problems similar to those for uninitialized variable analysis,
>> building too much goo into tree-ssa-uninit doesn't seem like a long term
>> solution.
>
> 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).
>
> Thanks,
> Richard.
>



More information about the Gcc-patches mailing list