On Mon, Aug 21, 2017 at 6:40 PM, Christopher Li <sparse@xxxxxxxxxxx> wrote:
>
> Do you have insight then why the SSSA is 2% slower than
> the RC5 without the short cut case? I expect with simpler
> effective approach it should be at least similar or faster.
> It do less work than RC5 in terms of finding dorminator etc.
I just made a small change to the ptrmap and I'm back to slightly
faster than rc5. With all March's pending fixes it's even a bit faster.
We're talking of something like twice 2%.
With smaller ptrlist it's yet another 2%.
>>> If we take that as an assumption. Then I have this idea similar
>>> to the SSSA paper in the sense that it take advantage of the
>>> source file that is reducible graph. Instead of inserting the phi
>>> instruction on all possible block join point.
>>
>> Mind to explain what you mean by 'all possible block join point' and
>> why you believe the method do this?
>
> I am reading the paper there seems to be recursive go through
> the parents.
Otherwise you could only process block local vars.
But going recursively through the parents is not something
expensive, especially since very few is done at each steps.
>> Don't you need the whole CFG for this (when you have
>> a loop, for example)?
>
> I haven't play out all the detail yet. The idea about the loop:
>
> while (expr_a()) {
> loop_body_blocks;
> }
> after_loop_blok;
>
> We known that every variable declare in the loop_body_blocks
> with indentation level == 2 is going to dominate the rest of the
> loop_body_blocks where line number > the current define place.
>
> And we know that that define domination ends at the last block
> in side loop_body_blocks for the same indentation level.
>
> We can have a stack system while we recursive linearize
> the statement. That is the idea. I haven't plan out the detail.
Sorry, but for my part I'll give my trust to a published and well
received method.
-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
