From owner-pro64-contrib@oss.sgi.com Wed Apr 4 14:19:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f34LJop32513 for pro64-contrib-outgoing; Wed, 4 Apr 2001 14:19:50 -0700 Received: from heart.hq.tensilica.com ([38.170.141.29]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f34LJoM32510 for ; Wed, 4 Apr 2001 14:19:50 -0700 Received: (from goodwin@localhost) by heart.hq.tensilica.com (8.9.3/8.9.3) id OAA17425; Wed, 4 Apr 2001 14:19:46 -0700 X-Authentication-Warning: heart.hq.tensilica.com: goodwin set sender to goodwin@tensilica.com using -f From: David Goodwin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15051.36850.461488.357484@heart.hq.tensilica.com> Date: Wed, 4 Apr 2001 14:19:46 -0700 (PDT) To: pro64-contrib@oss.sgi.com Subject: bug in low-level strtab insertion X-Mailer: VM 6.75 under Emacs 20.5.1 Reply-to: goodwin@tensilica.com Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk I think there's a bug here that's fixed with the following patch: ==== strtab.cxx ==== *************** *** 312,320 **** void STR_TAB::copy_str (const char *str, UINT32 size) { UINT32 buffer_size = STR::get_buffer_length (size); reserve (buffer_size); ! STR::copy (str, size, buffer + last_idx); last_idx += buffer_size; } // STR_TAB::copy_str --- 312,331 ---- void STR_TAB::copy_str (const char *str, UINT32 size) { + /* Here's a nasty one. If the call to "reserve" forces a + reallocation of the strings in the table, and 'str' happens to + point to a string in the table, then after the reallocation, + 'str' could point to garbage. Why are we inserting a string that + is already in the table? Because we don't detect duplicates till + after inserting (and then undo the insert; see + STR_TAB::insert above). So make a local copy of 'str' to + prevent that from happening. */ UINT32 buffer_size = STR::get_buffer_length (size); + char *new_str = (char *) alloca (buffer_size); + STR::copy(str, size, new_str); + reserve (buffer_size); ! STR::copy (STR::get_str(new_str), size, buffer + last_idx); last_idx += buffer_size; } // STR_TAB::copy_str From owner-pro64-contrib@oss.sgi.com Sat Apr 21 20:34:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f3M3YKu27210 for pro64-contrib-outgoing; Sat, 21 Apr 2001 20:34:20 -0700 Received: from beowulf.ucsd.edu (wchuang@beowulf.ucsd.edu [132.239.55.100]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f3M3YIM27207 for ; Sat, 21 Apr 2001 20:34:18 -0700 Received: from localhost (wchuang@localhost) by beowulf.ucsd.edu (8.9.1a/8.9.1) with SMTP id UAA23425; Sat, 21 Apr 2001 20:34:17 -0700 (PDT) Date: Sat, 21 Apr 2001 20:34:16 -0700 (PDT) From: Weihaw CHUANG To: pro64-contrib@oss.sgi.com cc: weihaw@yahoo.com Subject: compiler annotation for architecture studies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk Hi, I hope this is the right forum to discuss enhancements or availability of tools for the IA64 version of the osprey compiler. My question is, is there a binary annotation feature for osprey to help identify particular classes of instructions? For example I'm interested in studying the load/store cache miss rates for say stack based loads versus heap based loads. In IA64 this is not obvious due to the base only mode of the memory instructions. With an binary annotation tool, it might be possible to identify these instructions, annotate this information to a special data section in assembly, and have a timing simulator read them, to determine the cache effects. Various statistics could be collected and returned back to the user. If there isn't an annotator (probable situation), would there be someone in the osprey code generator group that I might be able to contact (very briefly I promise!) just to figure out where needed information is? Thanks! -Wei