[llvm-commits] CVS: llvm/lib/Reoptimizer/Inst/InstManip.h Phases.cpp design.txt

[Joel Stanley]

Changes in directory llvm/lib/Reoptimizer/Inst:

InstManip.h updated: 1.7 -> 1.8
Phases.cpp updated: 1.11 -> 1.12
design.txt updated: 1.8 -> 1.9

---
Log message:

Reading GBT contents correctly.
Preliminary load-tag matching now working.







---
Diffs of the changes:

Index: llvm/lib/Reoptimizer/Inst/InstManip.h
diff -u llvm/lib/Reoptimizer/Inst/InstManip.h:1.7 llvm/lib/Reoptimizer/Inst/InstManip.h:1.8
--- llvm/lib/Reoptimizer/Inst/InstManip.h:1.7	Tue Apr 15 16:26:19 2003
+++ llvm/lib/Reoptimizer/Inst/InstManip.h	Fri Apr 18 12:29:00 2003
@@ -5,7 +5,7 @@
 //     purpose: InstManip is a wrapper class around any BinInterface macros/mechanisms, as
 //     well as the TraceCache "instruction utilities", all which are (currently)
 //     SparcV9-specific.  This class exists both for conceptual clarity and to facilitate
-//     the hiding of Sparc-specific code from the Phase2/3 actions (and thus making it
+//     the hiding of Sparc-specific code from the Phase 2-4 actions (and thus making it
 //     easier to use the transformations on other platforms in the future; we should be
 //     able to change which instruction manipulator object is instantiated, after making
 //     the appropriate superclass, etc). 


Index: llvm/lib/Reoptimizer/Inst/Phases.cpp
diff -u llvm/lib/Reoptimizer/Inst/Phases.cpp:1.11 llvm/lib/Reoptimizer/Inst/Phases.cpp:1.12
--- llvm/lib/Reoptimizer/Inst/Phases.cpp:1.11	Tue Apr 15 16:26:19 2003
+++ llvm/lib/Reoptimizer/Inst/Phases.cpp	Fri Apr 18 12:29:00 2003
@@ -74,6 +74,17 @@
 using std::cerr;
 using std::endl;
 
+// Description of GBT contents emitted by phase 1. The extern reference to the GBT will be
+// resolved at link-time, and will point to the GBT itself. The size of the GBT is
+// obtained in the same manner.
+
+extern unsigned ppGBTSize;
+extern struct PrimInfo {
+    unsigned gbtType;
+    unsigned short* loadVar;
+    unsigned gbtStartIdx;
+} ppGBT[];
+
 typedef std::pair<uint64_t, uint64_t> AddressRange;
 
 class Phase3Info 
@@ -223,7 +234,7 @@
     AddressRange range;
 
     while(elfReader.GetNextFunction(funcName, range)) {
-        if(funcName == "l16_fibs") {
+        if(funcName == "fibs") {
             //cerr << "Printing information about function " << funcName << endl;
             //m_instManip.printRange(range.first, range.second);
 
@@ -325,8 +336,6 @@
     // write to it.  However, it does indeed pose a problem for multi-threaded codes.  A
     // modification to the general mechanism itself is required to achieve thread-safety.
 
-    cerr << "About to deallocate phase2-created slot" << endl;
-
     uint64_t slotBase = m_pPhase3Info->getSlot();
     unsigned slotSize = m_pPhase3Info->getSlotSize();
     m_pTraceCache->getMemMgr()->freeTraceMemory(slotBase, slotSize);
@@ -428,4 +437,18 @@
     p4info->getTraceCache()->getVM()->writeInstToVM(p4info->getCandidate().front().first,
                                                     p4info->getCandidate().front().second);
     delete p4info;
+
+    cerr << "ppGBT is: " << ppGBT << endl;
+    cerr << "ppGBTSize is: " << ppGBTSize << endl;
+
+    for(int i = 0; i < ppGBTSize; ++i) {
+        cerr << "ppGBT[" << i << "]: " << ppGBT[i].gbtType << ", "
+             << ppGBT[i].loadVar << ", " << ppGBT[i].gbtStartIdx << endl;
+    }
+    
+    // tmp
+    if(tag == (uint64_t)(ppGBT[0].loadVar)) {
+        cerr << "TAG MATCHES, BOYYYYYYYYYYY!" << endl;
+    }
+    // tmp
 }


Index: llvm/lib/Reoptimizer/Inst/design.txt
diff -u llvm/lib/Reoptimizer/Inst/design.txt:1.8 llvm/lib/Reoptimizer/Inst/design.txt:1.9
--- llvm/lib/Reoptimizer/Inst/design.txt:1.8	Thu Apr 10 17:34:16 2003
+++ llvm/lib/Reoptimizer/Inst/design.txt	Fri Apr 18 12:29:00 2003
@@ -920,6 +920,37 @@
       Approach B: Other phases use heap-managed dynamic memory; no dummy
       function needed.
 
+      GBT construction:
+      
+      In the KIS prototype implementation, the GBT will be an array of structs.  Each
+      struct will contain:
+
+          - The type of metric (i.e. COUNTER, POINT, REGION)
+
+	  - The pointer to the global volatile whose load represents an instrumentation
+	    site.
+
+	  - Other information, such as what function to call, etc.
+
+       The complicated thing that must be handled here is how to relate interval metrics
+       to each other in a pairwise manner. Consider the following scenario: Phase 4 is
+       triggered for a particular start interval site, and the GBT is consulted to
+       determine that the candidate is indeed a load-volatile. A new slot is written
+       containing the call to the instrumentation code, etc, together with an alloca for
+       the temporary, etc.  So far, so good. Now...we must pass the address of this
+       alloca'd temporary to the function invoked at the end-interval site.  However, when
+       we encounter the end-interval site, all we do is look up in the GBT and determine
+       that we have a valid load-volatile site.  What we need is two distinct types to
+       describe the struct contents: INTERVAL_START, and INTERVAL_END:
+
+       If INTERVAL_START, we have a link to the alloca'd temporary, and that is stored
+       when the start-interval site is processed.  If INTERVAL_END, we have a link back to
+       the corresponding INTERVAL_START record, which contains the link to the alloca'd
+       temporary.  Since the intervals are pairwise-processed in Phase 1 (although this
+       needs to be made more robust, etc, it is clear that the pairwise matching ought to
+       be done at the sigfun/parser level as opposed to at the machine code level), the
+       structure records can indeed be constructed in this manner.
+
   In phase 2:
 
   On program startup ("phase 2" function called from main()):