Hello, all

I have attached an updated version of bug fix to #707.

--------------------------------------------------------------------------------------------------------------------------------------------------
The following code snippet:

loc = 0; buffer[limit] = 33;
while (buffer[loc] == 32 || buffer[loc]==9)
  loc += 1;

will be lowered into:

loc = 0;
buffer[limit] = 33;
if (buffer[loc] == 32)
  goto L6146;
if (!(buffer[loc] == 9))
  goto L5890;
L6146:
   loc +=1
  if (buffer[loc] == 32)
    goto L6146;
  if (buffer[loc] == 9)
   goto L6146;
L5890:


which will then be converted into the following form after SSA

loc = 0
buffer[limit] = 33
sym5v29 = chi (sym5v16)  //sym5 is for buffer array
sym8v30 = chi (sym8v19)  //sym8 is for buffer[0], marked to be NOT LIVE by DSE

mu (sym5v29)                 // because buffer[loc] is converted into
ILOAD (LDA buffer + loc) form
if (buffer[loc] == 32)
  goto L6146;
if (!(buffer[loc] == 9))
  goto L5890;


Then, in creating HSSA representation, the code finds that loc can be
propagated during iload_folded. So, sym8v30 is resurrected, and
buf[loc] ==32 is converted into ILOAD (LDA buffer[0]). However, the
original code failed to change all subsequent references of sym8v19
back to sym8v30 (essentially undo what DSE did), causing the their
live ranges to intersect and hence the assertion failure.

Since sym8v30 = chi (sym8v19) is not live at the time of
find_zero_versions, sym8v30 is marked as zero version. This results in
Get_zero_version_CR being called in Create_CODEMAP to create CODEREP
for sym8v30.  This is what the new fix tries to address. The changing
of references means that: 1) sym8v19 might change from having real
occurrence to no real occurrence 2) sym8v30 should have real
occurrences now (because of the ILOAD folding). What the fix does is
try to mark them as not zero versioning (thus having real occurrences)
conservatively. This might not be as accurate as performing a new
round of find_zero_versions again (which I think might be too costly).

-- Feng



On Wed, Feb 9, 2011 at 5:14 PM, Sun Chan <sun.c...@gmail.com> wrote:
> Can you show the code for resurrect_chi? The proposed source change is
> quite big, yet, standard, I'd like to know if something is missing, or
> if there is already existing code that does similar thing
> Sun
>
> On Thu, Feb 10, 2011 at 8:52 AM, Min Zhao <mzhao...@gmail.com> wrote:
>>
>> You mean the source code of iload folding? It is in opt_htable.cxx (from
>> line 2874).
>>
>> Here is where to do resurrect,opt_htable.cxx :
>>
>>    2875     // go thru chi list to find the scalar var version
>>    2876     CHI_NODE *cnode;
>>    2877     CHI_LIST_ITER chi_iter;
>>    2878     FOR_ALL_NODE(cnode, chi_iter, Init(dstmt->Chi_list())) {
>>    2879       vaux = cnode->Aux_id();
>>    2880       if (!Sym()->Is_real_var(vaux))
>>    2881         continue;
>>    ....
>>    2886       if (...) { // find the match sym
>>    2899         base_ccr->Tree()->DecUsecnt();  // for the LDA coderep
>>    2900         _ssa->Value_number_mu_node(Sym()->Get_mem_mu_node(wn));
>>    2901         if (! cnode->Live()) {
>>    2902           _ssa->Resurrect_chi(cnode);
>>    2903           cnode->RESULT()->Set_defstmt(dstmt);
>>    2904        }
>>
>>
>>
>>
>> On Wed, Feb 9, 2011 at 4:21 PM, Sun Chan <sun.c...@gmail.com> wrote:
>>>
>>> can you include the code in iload folding that tries to do the same
>>> thing, i.e. resurrect the version?
>>> Thx!
>>> Su
>>>
>>> On Thu, Feb 10, 2011 at 8:08 AM, Min Zhao <mzhao...@gmail.com> wrote:
>>> >
>>> > Yes.
>>> >
>>> > On Wed, Feb 9, 2011 at 4:08 PM, Sun Chan <sun.c...@gmail.com> wrote:
>>> >>
>>> >> S2 doms S5?
>>> >> Sun
>>> >>
>>> >> On Thu, Feb 10, 2011 at 7:55 AM, Min Zhao <mzhao...@gmail.com> wrote:
>>> >> >
>>> >> > Sorry, I should NOT use v0 as an example version. For better
>>> >> > explanation,
>>> >> > using the real verions in the code:
>>> >> >
>>> >> > S1: loc = 0;
>>> >> > S2: buffer[limit] = 33;
>>> >> >            sym3v18 = chi (sym3v11) // buffer
>>> >> >            sym5v19 = chi (sym5v13) // buffer scalar var -> NOT LIVE
>>> >> > by
>>> >> > DSE
>>> >> > -> LIVE by ILOAD_FOLD
>>> >> > S3: if (buffer[loc] != 10)
>>> >> >           mu(sym3v18)         // change to LDID (sym5v19) by
>>> >> > ILOAD_FOLD
>>> >> > S4:     loc = loc + 1;
>>> >> > S5: buffer[limit] = 32;
>>> >> >           sym3v24 = chi (sym3v18)
>>> >> >           sym5v25 = chi (sym5v19)  // change to sym5v25 = chi
>>> >> > (sym5v13)
>>> >> > by
>>> >> > DSE
>>> >> > S6: if (buffer[0] == 15)
>>> >> >
>>> >> > Although sym5v19 = chi (sym5v13) is resurrected, sym5v25 = chi
>>> >> > (sym5v13)
>>> >> > is
>>> >> > still using sym5v13, instead of sym5v19.
>>> >> >
>>> >> > On Wed, Feb 9, 2011 at 2:48 PM, Sun Chan <sun.c...@gmail.com> wrote:
>>> >> >>
>>> >> >> i still don't understand why you think you can use v1, the more
>>> >> >> precise version, instead of zero version? This is more than just a
>>> >> >> versioning problem. It is a precision problem, isn't it?
>>> >> >> Sun
>>> >> >>
>>> >> >> On Thu, Feb 10, 2011 at 2:56 AM, Min Zhao <mzhao...@gmail.com>
>>> >> >> wrote:
>>> >> >> > More explanations.
>>> >> >> >
>>> >> >> > Here is the failing test case:
>>> >> >> >
>>> >> >> > S1: loc = 0;
>>> >> >> >
>>> >> >> > S2: buffer[limit] = 33;
>>> >> >> >
>>> >> >> >            sym3v1 = chi (sym3v0) // buffer
>>> >> >> >
>>> >> >> >            sym5v1 = chi (sym5v0) // buffer scalar var -> NOT LIVE
>>> >> >> > by
>>> >> >> > DSE ->
>>> >> >> > LIVE by ILOAD_FOLD
>>> >> >> >
>>> >> >> > S3: if (buffer[loc] != 10)
>>> >> >> >
>>> >> >> >           mu(sym3v1)         // change to LDID (sym5v1) by
>>> >> >> > ILOAD_FOLD
>>> >> >> >
>>> >> >> > S4:     loc = loc + 1;
>>> >> >> >
>>> >> >> > S5: buffer[limit] = 32;
>>> >> >> >
>>> >> >> >           sym3v2 = chi (sym3v1)
>>> >> >> >
>>> >> >> >           sym5v2 = chi (sym5v1)  // change to sym5v2 = chi
>>> >> >> > (sym5v0)
>>> >> >> > by
>>> >> >> > DSE
>>> >> >> >
>>> >> >> > S6: if (buffer[0] == 15)
>>> >> >> >
>>> >> >> >           mu (sym5v2)
>>> >> >> >
>>> >> >> >   ...
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > Since there is no use of sym5v1 between S2 and S5, DSE 1) marks
>>> >> >> > “sym5v1
>>> >> >> > =
>>> >> >> > chi (sym5v0)” as NOT LIVE 2) changes the chi in S5 to sym5v2 = chi
>>> >> >> > (sym5v0).
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > Later, in the Create_CODEMAP, ILOAD_FOLD is done for buffer[loc],
>>> >> >> > which
>>> >> >> > is
>>> >> >> > buffer[0]. Now sym5v1 is used. ILOAD_FOLD resurrect the chi,
>>> >> >> > sym5v1 =
>>> >> >> > chi
>>> >> >> > (sym5v0). But the problem is that after resurrect_chi, sym5v2 =
>>> >> >> > chi
>>> >> >> > (sym5v0)
>>> >> >> > is still using sym5v0 instead of sym5v1. Thus, overlapping live
>>> >> >> > range
>>> >> >> > problem happens.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > The fix is to change all appropriate uses of sym5v0 to sym5v1.
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>

Attachment: bug707_v2.patch
Description: Binary data

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to