Not sure I completely understand what you are doing, but it sounds like you need to study how ipa and the inliner handle the symbol table. The local symbol table for each pu is normally replaced for each pu (e.g. symbol indexed by <2,1> is a different symbol, depending on the PU). So you'd need to manage the scope_tab if you want to move between scopes.
-----Original Message----- From: Jeremy Abramson [mailto:abram...@isi.edu] Sent: Tuesday, June 22, 2010 12:33 AM To: open64-devel@lists.sourceforge.net Subject: Re: [Open64-devel] Best way to get at a symbol name in whirl / symbol table memory scoping? Thanks for responding Mike! Thanks for the tip on WN_has_sym(). Ideally what I was looking for is something robust will look at a WN and not punt if you're not accessing the appropriate fields. I've defined my own functions to do just that, but I thought there [other] functions in Open64 internally that would do the same thing. Most of this involves looking at the string table, and there are plenty of opcodes with valid ST entries, but completely invalid indexes into the string table. I just assumed ST_name() would take care of that for me, but you know what happens when you assume.... More pressing is my issue with symbol table memory scope. Basically what I'm doing is loading a .B file, iterating through it, building external data structures that associate themselves with a particular WN, and then accessing those structures to get at the WN (and the information the WN possesses, most importantly, symbol information). A clear example of this is building a data flow graph. My problem arises that when I change my program structure, as you stated, most/many of the symbol table entries became invalid. Since there isn't very good (any!) documentation on the memory pool management, and the comments in files like ir_bread.cxx aren't super helpful, I was just wondering if there's a way to load a .B file, iterate across the PUs, iterate across each WN in a PU and have the symbol table be valid/still in memory across the lifetime of my program? I'm really pulling my hair out over this. I've been playing with a stripped version of ir_b2a that just adds WN in to a vector and then reads them later. And it's interesting to see when iterating across the vector seg faults and when it doesn't. I've tried every permutation of memory pool statement (removing statements like: MEM_POOL_Pop(MEM_pu_nz_pool_ptr) and MEM_POOL_Pop(MEM_pu_pool_ptr) ). It pretty much seems that across function calls, there really isn't a way of keeping the symbol table in memory, and since I need to iterate the AST recursively, I'm not sure how to do it globally. Any help would be GREATLY appreciated. Is there a way of keeping the symbol table valid for the lifespan of my program? J. open64-devel-requ...@lists.sourceforge.net wrote: > Message: 2 > Date: Fri, 18 Jun 2010 15:33:38 -0700 > From: Mike Murphy <mmur...@nvidia.com> > Subject: > To: 'Jeremy Abramson' <abram...@isi.edu>, > "open64-devel@lists.sourceforge.net" > <open64-devel@lists.sourceforge.net> > Message-ID: > <918f40269c813345a23f8c3667820306180168a...@hqmail03.nvidia.com> > Content-Type: text/plain; charset="us-ascii" > > 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
