Redo the way cachegrind generates instrumentation code, so that it can

deal with any IR that happens to show up.  This makes it work on ppc32
and should fix occasionally-reported bugs on x86/amd64 where it bombs
due to having to deal with multiple date references in a single
instruction.

The new scheme is based around the idea of a queue of memory events
which are outstanding, in the sense that no IR has yet been generated
to do the relevant helper calls.  The presence of the queue --
currently 16 entries deep -- gives cachegrind more scope for combining
multiple memory references into a single helper function call.  As a
result it runs 3%-5% faster than the previous version, on x86.

This commit also changes the type of the tool interface function
'tool_discard_basic_block_info' and clarifies its meaning.  See
comments in include/pub_tool_tooliface.h.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4903

coregrind/m_tooliface.c

@@ -154,7 +154,7 @@ NEEDS(core_errors)
 NEEDS(data_syms)
 
 void VG_(needs_basic_block_discards)(
-   void (*discard)(Addr, SizeT)
+   void (*discard)(VexGuestExtents)
 )
 {
    VG_(needs).basic_block_discards = True;

coregrind/m_transtab.c

@@ -610,9 +610,14 @@ void VG_(discard_translations) ( Addr64 guest_start, ULong range,
              && overlaps( guest_start, range, &sectors[sno].tt[i].vge )) {
             sectors[sno].tt[i].status = Deleted;
             sectors[sno].tt_n_inuse--;
-              anyDeleted = True;
+            anyDeleted = True;
             n_disc_count++;
             n_disc_osize += vge_osize(&sectors[sno].tt[i].vge);
+            /* Tell the tool too. */
+            if (VG_(needs).basic_block_discards) {
+               VG_TDICT_CALL( tool_discard_basic_block_info,
+                              sectors[sno].tt[i].vge );
+            }
          }
       }    
    }

coregrind/pub_core_tooliface.h

@@ -121,7 +121,7 @@ typedef struct {
    void  (*tool_print_extra_suppression_info)(Error*);
 
    // VG_(needs).basic_block_discards
-   void (*tool_discard_basic_block_info)(Addr, SizeT);
+   void (*tool_discard_basic_block_info)(VexGuestExtents);
 
    // VG_(needs).command_line_options
    Bool (*tool_process_cmd_line_option)(Char*);

include/pub_tool_tooliface.h

@@ -186,17 +186,28 @@ extern void VG_(needs_tool_errors) (
    void (*print_extra_suppression_info)(Error* err)
 );
 
-
-/* Is information kept about specific individual basic blocks?  (Eg. for
-   cachegrind there are cost-centres for every instruction, stored at a
-   basic block level.)  If so, it sometimes has to be discarded, because
-   .so mmap/munmap-ping or self-modifying code (informed by the
-   DISCARD_TRANSLATIONS user request) can cause one instruction address
-   to be used for more than one instruction in one program run...  */
+/* Is information kept by the tool about specific instructions or
+   translations?  (Eg. for cachegrind there are cost-centres for every
+   instruction, stored in a per-translation fashion.)  If so, the info
+   may have to be discarded when translations are unloaded (eg. due to
+   .so unloading, or otherwise at the discretion of m_transtab, eg
+   when the table becomes too full) to avoid stale information being
+   reused for new translations. */
 extern void VG_(needs_basic_block_discards) (
-   // Should discard any information that pertains to specific basic blocks
-   // or instructions within the address range given.
-   void (*discard_basic_block_info)(Addr a, SizeT size)
+   // Discard any information that pertains to specific translations
+   // or instructions within the address range given.  The "extents"
+   // arg can be used in two ways.
+   // - If info is being stored at a per-translation level, the first
+   //   address in the extents can be used to identify which translation
+   //   is being discarded.  Each translation will be discarded exactly
+   //   once.
+   // - If info is being stored at a per-instruction level, you can get
+   //   the address range(s) being discarded by stepping through "extents".
+   //   Note that any single instruction may belong to more than one
+   //   translation, and so could be covered by the "extents" of more than
+   //   one call to this function.
+   // Doing it the first way (as eg. Cachegrind does) is probably easier.
+   void (*discard_basic_block_info)(VexGuestExtents vge)
 );
 
 /* Tool defines its own command line options? */