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.
Eric
----- Original Message -----
From: Sun Chan
To: eirc.lew
Cc: Mike Murphy ; Jeremy Abramson ; open64-devel@lists.sourceforge.net
Sent: Monday, June 21, 2010 11:03 AM
Subject: Re: [Open64-devel] Best way to get at a symbol name in whirl /
symbol table memory scoping?
L2 with sym=258 is obviously not a pointer. Meaning, you did not create the
symbol correctly
Sun
On Sun, Jun 20, 2010 at 5:51 PM, eirc.lew <eirc....@gmail.com> wrote:
Hi,
I have encountered some problem about ST and WN. When I can access the ST
in function create_locals, and I can get the st_idx, and the ST_name(st_idx)
return the right name_str, but When I call the function below:
// 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?
Eric
----- Original Message -----
From: Mike Murphy
To: 'Jeremy Abramson' ; open64-devel@lists.sourceforge.net
Sent: Saturday, June 19, 2010 7:33 AM
Subject: Re: [Open64-devel] Best way to get at a symbol name in whirl /
symbol table memory scoping?
To know whether a wn has a symbol name, use WN_has_sym().
For your other problem, sounds like maybe the string table is being
corrupted; the name is just an index into the string table.
-----Original Message-----
From: Jeremy Abramson [mailto:abram...@isi.edu]
Sent: Friday, June 18, 2010 3:02 PM
To: open64-devel@lists.sourceforge.net
Subject: [Open64-devel] Best way to get at a symbol name in whirl /
symbol table memory scoping?
I'm my travels, I often build external structures that relate to the
WHIRL tree. And often I need to know if a WN has a symbol name. I
originally -- and naively -- did this before thinking I could test on
the return value of WN_st, and then use ST_name to get at the entry in
the string table / the symbol name. Sounds reasonable, but there are
many whirl nodes for which WN_st(wn) simply punts (choking on the
"Entry" function in cmplr_segmented_array.h at line return map[idx /
block_size].first[idx % block_size]). I got around this through trial
and error, and now I don't test nodes for which I know the WN_st will
punt (although I'm not sure why merely attempting to return a st for a
node that doesn't have one wouldn't just return null).
My first question is: There's obviously a better way of getting at the
symbol name (if one exists) of a whirl node. Anyone have any ideas?
My second question deals with [I think, I'm pretty unclear about most of
this] the symbol table and memory allocation/scoping. I have a program
that opens a .B file, iterates through its contents, generates a CFG and
then a DFG for each basic block. This is done in steps, from various
functions in an attempt to have decent top-down design. It seems that
seems that somewhere along the way, I'm "losing" some symbol names (for
various STID nodes, mostly). Which is to say, if I dump the IR output
in a format much like ir_walker or ir_b2a, I can see each node and each
symbol name. But after computing the CFG, when I walk through the nodes
in the CFG, some of the nodes no longer [seemingly?] have symbol names.
The st/st_idxs match and are valid, but ST_name no longer returns
anything.
So, this is possibly a bug in my system (wouldn't be the first =] ), but
I can't see where that would be, so I was wondering if perhaps I'm not
allocating (or am de-allocating?) the memory pool for the symbol table.
Not all the symbols names are "lost", so it's pretty confusing. Is
there a primer somewhere on the memory management done in Open64, mainly
as it pertains to the symbol table? As it stands now, I'm attempting to
follow a pattern similar to the one in ir_b2a, but I don't have a
fundamental understanding of how/why the memory handling works and I'd
like to understand it better.
Thanks a ton!
Jeremy
------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
