Hi,all
The problem is gone and I realized it as shuxin yang mentioned. The steps as
follow:
1)gather the local private vars I will ref in the new_pu;
2)if the var in orig_pu will be changed to preg, then generate a temp_var for
the var and Set_ST_has_nested_ref(temp_var_st);
3)in the new pu, when want to ref var, instead we access temp_var;
So now the problem is done.
Thanks a lot.
Eric
----- Original Message -----
From: shuxin yang
To: Mike Murphy
Cc: eirc.lew ; open64-devel@lists.sourceforge.net
Sent: Tuesday, June 22, 2010 5:33 AM
Subject: Re: [Open64-devel] Best way to get at a symbol name in whirl /
symbol table memory scoping?
Yes, 258 is st_idx instead of pointer. It is the first symbol (258>>8)
of level 2 (258 & 0xff).
I suspect the symbol whose st-idx is 258 is reset for some reasons. Say,
the compiler
may replace the symbol with a PREG symbol. Set_ST_has_nested_ref(st)
will prevent
compiler from doing such opt.
Shuxin
Mike Murphy wrote:
> 258 is probably the st_idx, rather than ST*. The idx is what is stored in
the whirl.
>
> -----Original Message-----
> From: shuxin yang [mailto:shuxinyang2...@gmail.com]
> Sent: Monday, June 21, 2010 1:22 PM
> To: eirc.lew
> Cc: open64-devel@lists.sourceforge.net
> Subject: Re: [Open64-devel] Best way to get at a symbol name in whirl /
symbol table memory scoping?
>
> It sounds very weird to me.
> I think the symbol with st-idx=258 is corrupted for some reasons.
>
> Do you call Set_ST_has_nested_ref(st) for the symbol defined in the
> nesting func and
> ref in the nested func? If you don't, you certainly has problem in WOPT
> (where uplevel reference is lowed)
> and downstream phases. I don't know if lacking such flags will incur
> problems in earlier phases.
> It is likely possible.
>
> Anyway, you can set a breakpoint at New_ST to catch the moment symbol
> 258 is created,
> and made a hw watch to its content. Then gdb will tell you when the
> symbol is corrupted.
>
> If you cannot make a break at this function, you probably need to turn
> on -fno-inline when
> building the compiler.
>
> osprey/common/com/symtab.h
> 94 inline ST*
> 95 New_ST (SYMTAB_IDX level)
> 96 {
> 97 UINT idx;
> 98 ST& s = Scope_tab[level].st_tab->New_entry (idx);
> 99 // Clear the random padding bits in ST.
> 100 // Otherwise, these random paddings may make bcmp/memcmp
> mis-compare.
> 101 memset(&s, 0, sizeof(ST)); // bug 14141
> 102 Set_ST_st_idx (s, make_ST_IDX (idx, level));
> 103 return &s;
> 104 }
>
> Shuxin
>
>
> eirc.lew wrote:
>
>> Hi,
>> Thank you for your reply.
>> The symbol I created is right, and the reason it encounters errors, I
>> think it is because I create a child pu named childpu and the childpu
>> nested in the parent pu of ppu, When I do the same thing in the ppu,
>> it seems all right.
>> What I want to do is to create a new symbol sym in childpu which
>> correspond to the symbol of orig_st in ppu, and I want to do is:
>> sym = orig_st;
>> But, when I want to LDID orig_st, it seems I can't do it this way.
>>
>> Actually, what I want to do is like the inline_micro_task in OpenMP of
>> open64, for example:
>>
>> int mian()
>> {
>> int sum = 10;
>> int add()
>> {
>> for(int i = 0; i < 10; i++)
>> L1: sum += i;
>> return sum;
>> }
>> return 0;
>> }
>>
>> I want to realize the L1 line by reconstruct the whirl tree of
>> the program.
>>
>>
>>
>>
>> // in this function ,I can access orig_st and new_st by
>> ST_name(orig_st);
>> Gen_MP_Load_Store(v->orig_st, v->orig_offset, v->new_st,
>> v->new_offset, v->is_dynamic_array)
>> // in this function, ST_name(from_st) returns "i", the
>> result is right.
>> Gen_MP_Load ( from_st, from_offset )
>> L1: WN_RLdid (rtype=4, desc=4, offset=0, *sym=0x80920dc*,
>> align=14850);// ST_name(sym) return the right result
>> L2 WN_RLdid (rtype=4, desc=4, offset=0, *sym=258*,
>> align=14850) // sym is st_idx, and ST_name(sym) return error;
>>
>>
>> L3: WN_CreateLdid (opr=OPR_LDID, rtype=4, desc=4,
>> offset=0,* st=258*, ty=14850, field_id=0)
>>
>> because the WN return from WN_CreatedLdid include the symbol
>> of st, but when I do like below:
>> p dump_tree(wn), it corrupts,
>> but When do: p dump_tree_no_st(wn)， it returns the right
>> result as below:
>> I4I4LDID 0 <null-st> T<### ERROR: null ptr>
>>
>> But, I find sometime the same operation on L2, it is also
>> right, but this it fails.
>>
>> What is the reason?
>>
>>
>>
>>
>
>
>
------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
-----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may
contain
> confidential information. Any unauthorized review, use, disclosure or
distribution
> is prohibited. If you are not the intended recipient, please contact the
sender by
> reply email and destroy all copies of the original message.
>
-----------------------------------------------------------------------------------
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
