A question about bytecodes + unsigned load performance ./. add performace

[Vladimir Kozlov]

I looked on your previous post.

Again there is no enough information.
Is this graph produced after you changed something in C2?
311 is the loop's entry control so LoadB is placed
outside the loop but AndI and StoreC is inside the loop.
This makes no sense for this case.

Christian, I would suggest to look on this loop before first
unrolling/peeling.
You may use visualizer to see how the graph evolves.

Vladimir

Christian Thalinger wrote:
> On Thu, 2009-01-15 at 09:44 -0800, Vladimir Kozlov wrote:
>> The loop in match_into_reg() is simplified check for
>> control nodes domination. You have to follow all
>> merging paths above a region to check that they all dominate.
>> And since it didn't reach m->in(0) we can not say that it dominates
>> so we bailout.
>>
>> I wonder what are different control nodes. One is a loop head (region),
>> I assume, and an other? And why AndI has control edge?
>>
>> AndI	===  458  129  140  [[ 164 ]]
> 
> Here are the nodes:
> 
>  141    AndI    ===  458  129  140  [[ 164 ]]  !orig=[377] !jvms: test::decode @ bci:4 test::bar @ bci:29
> 
>  458    CountedLoop     ===  458  311  172  [[ 438  439  440  441  457  458  346  461  164  204  141  347 ]] inner stride: 4 main of N458 !orig=[359],[205],[184],[100] !jvms: test::bar @ bci:22
>  129    LoadB   ===  311  51  127  [[ 141 ]]  @byte[int:>=0]:exact+any *, idx=4; #byte !jvms: test::bar @ bci:28
>  140    ConI    ===  0  [[ 141  217  268  347  439  441 ]]  #int:255
> 
>  164    StoreC  ===  458  346  162  141  [[ 295  461 ]]  @char[int:>=0]:exact+any *, idx=5;  Memory: @char[int:10]:NotNull:exact+any *, idx=5; !orig=[376] !jvms: test::bar @ bci:32
> 
> Did you know that AndI has a control edge from the node output above or
> from my previous posting?
> 
> -- Christian
>