| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | Remove attribution from file headers, per discussion on llvmdev. | Chris Lattner | 2007-12-29 | 1 | -2/+2 |
| | | | | | llvm-svn: 45418 | ||||
| * | Add explicit keywords, and fix a minor typo that they uncovered. | Dan Gohman | 2007-12-14 | 1 | -1/+1 |
| | | | | | llvm-svn: 45034 | ||||
| * | CollectorMetadata and Collector are rejiggered to get along with | Gordon Henriksen | 2007-12-11 | 1 | -31/+61 |
| | | | | | | | | per-function collector model. Collector is now the factory for CollectorMetadata, so the latter may be subclassed. llvm-svn: 44827 | ||||
| * | CollectorMetadata abstractly describes stack maps for a function. | Gordon Henriksen | 2007-09-27 | 1 | -0/+185 |
| It includes: - location and of each safe point in machine code (identified by a label) - location of each root within the stack frame (identified by an offset), including the metadata tag provided to llvm.gcroot in the user program - size of the stack frame (for collectors which want to cheat on stack crawling :) - and eventually will include liveness It is to be populated by back-ends during code-generation. CollectorModuleMetadata aggregates this information across the entire module. llvm-svn: 42418 | |||||
 |
index : bcm5719-llvm | |
| Project Ortega BCM5719 LLVM | Raptor Computing Systems |
| summaryrefslogtreecommitdiffstats |
|