This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fix for pr47837
On Sat, Mar 12, 2011 at 1:44 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Fri, Mar 11, 2011 at 11:50 AM, Jeff Law <law@redhat.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/09/11 09:24, Xinliang David Li wrote:
>>> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law <law@redhat.com> wrote:
>>> On 03/09/11 02:45, Richard Guenther wrote:
>>>>>> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law <law@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?
>> Our current jump threading is just a special case of path isolation; the
>> biggest problem with path isolation is exploding codesize.
>
> Jump threading can reduce size in some cases -- due to more aggressive
> cleanups -- the -Os need to be more intelligent about it.
>
>>
>> I'd like to see that code generalized in a few ways based on well known
>> algorithms rather than the ad-hoc stuff we've got now keeping a
>> reasonable knob on the codesize bloat.
>>
>> In cases where we want more accurate warnings, but aren't willing to
>> accept the size bloat, on the side structures might be the way to go.
>>
>> I'm still looking a literature on the subject, but there's clearly
>> things we can do to improve the path sensitivity of the optimizers and
>> warning analysis.
>
> There are actually many papers on this (e.g. IMPACT group) ?as a
> result of research for EPIC optimizations (predication and if
> convert). Most of them talk about predicate query systems (efficient
> and accurate), e.g PQS using partition graph, PAS using BDD etc. ?The
> predicates relation can be built as side data structure, and the
> following queries can be made:
>
> ?p1 = get_predicate (gimple_stmt1);
> ?p2 = get_predicate (gimple_stmt2);
>
> if (is_disjoint (p1, p2) )
> ?..
> else if is_subset(p1, p2).
> ? ..
>
> Keeping the information up to date with transformations can be difficult.
Sure, I'd say this is a clear candidate for something that would get
re-computed if needed.
Richard.