GitHub PushEvent at 2014-01-31 17:56:13
Repository: ghc
Actor: scpmw
Payload: {"shas":[["17dec0ea9d6c1f4ccd739b90c4b2d11446dc47e0","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Source notes (Core support)\n\nThis patch introduces \"SourceNote\" tickishs that carry a reference to the\noriginal source code. They are meant to be passed along the compilation\npipeline with as little disturbance to optimization processes as possible.\n\nGeneration is triggered by command line parameter -g. It's free and\nfits with the intended end result (generation of DWARF). Internally we\nsay that we compile with \"debugging\", which is probably at least\nslightly confusing given the plethora of other debugging options we have.\n\nNote that this pass creates *lots* of tick nodes. We take care to\nremove duplicated and overlapping source ticks, which gets rid of most\nof them. Possible optimization could be to make Tick carry a list of\nTickishs instead of one at a time.\n\nKeeping ticks from getting into the way of Core transformations is\ntricky, but doable. The changes in this patch produce identical Core\nin all cases I tested (nofib). We should probably look for a way to\nmake a test-case out of this.","Peter Wortmann",true],["385f6a876325b9378995e3e60919a9c330d89b66","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Generalized Coverage pass to allow adding multiple types of Tickishs\n\nThis allows having, say, HPC ticks, automatic cost centres and source\nnotes active at the same time.","Peter Wortmann",true],["589c53bbbd2a7b198d4af0464fd41607588806fb","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Source notes (CorePrep and Stg support)\n\nThis is basically just about continuing maintaining source notes after\nthe Core stage. Unfortunately, this is more involved as it might seem,\nas there are more restrictions on where ticks are allowed to show up.\n\nDesign decisions:\n\n* We replace the StgTick / StgSCC constructors with a unified StgTick\n  that can carry any tickish.\n\n* For handling constructor or lambda applications, we generally float\n  ticks out.\n\n* However for bindings we float ticks inwards and even discard them for\n  constructors, as there is no good place to put them (mkTopStgRhs,\n  mkStgRhs). The only real argument against it would be that for\n  non-top-level bindings, the allocation cost ends up not being covered\n  by the tick in question.\n\n* Where CorePrep floats out lets, we make sure to wrap them in the same\n  spirit as FloatOut.","Peter Wortmann",true],["59a5945b84ed4dc00e4dad5eaf701d75b5cb47c3","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Strip source ticks from iface code if DWARF is disabled\n\nThey would be unneeded at minimum.","Peter Wortmann",true],["478625321afc64c63876f602ea221401e151728b","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Source notes from Core dumps\n\nThis patch allows source notes to refer to --ddump-to-file Core dumps, so\nwe can have debugging data refer directly to places in the Core. The\nimplementation is slightly tricky, as we couldn't find a way to get Pretty\nto generate line number information for us. Instead, we now generate\n\"annotations\" into the dump that get stripped out later, yielding line\nnumbers as we go along.","Peter Wortmann",true],["269d8ff38b82c68a0f26c0765a3b66f318c9ed9d","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Core notes\n\nThese tickishs are meant to carry the (simplified and prepared) Core\nthrough the later compilation stages.\n\nNotes:\n\n* Core notes are only useful in certain scenarios (mostly profiling),\n  and will end up taking up significant space in object files. We therefore\n  use another GHC flag (-fsave-core) to decide whether we annotate them or\n  not.\n\n* Annotations happen after CorePrep. This is slightly tricky, as CoreToStg\n  moves ticks around even after this point. We have to be careful to ensure\n  ticks end up where we intend them to be.\n\n* We take the easy route to just \"point\" into the Core code directly.\n  This is slightly awkward given that Core is normally a more stright-\n  forward data structure. We have to short-circuit Eq/Ord, for example.\n\n* We only annotate the interesting control flow points, which are\n  either top-level or let binding bodies as well as case branches.\n\n* In order to establish an identity and later perform sub-expression\n  checks, we safe a binder (of the binding or case) and the case\n  constructor (if applicable, otherwise __DEFAULT).","Peter Wortmann",true],["3a2cc013d66e9a10e190c48588fd310f2ba7b6cf","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Source notes (Cmm support)\n\nThis patch adds CmmTick nodes to Cmm code. On their own these ticks are\nnot useful yet, as there will be many blocks that lack annotation - and\nwe have no way of deriving them.\n\nNotes:\n\n* We use this design over, say, putting ticks into the entry node of all\n  blocks, as it seems to work better alongside existing optimisations.\n  Now granted, the reason for this is that currently GHC's main Cmm\n  optimisations seem to mainly reorganize and merge code, so this might\n  change in the future.\n\n* We have the Cmm parser generate a few source notes as well. This is\n  relatively easy to do - worst thing is that it blows up the CmmParse\n  implementation a bit.","Peter Wortmann",true],["e265d7ea78b0a0c0664fd5800b70779c891a7322","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","CmmContext nodes\n\nThis is the plumbing to allow us to define a proper association scheme\nfor blocks that have no source ticks on their own. The idea is basically\nthat all but top-level entry blocks are created in the *context* of\nanother block, and therefore are covered by any ticks of that block or,\nin turn, its parents.\n\nNotes:\n\n* As explained in the paper, this is basically about following causality\n  backwards: the context of every block is a block that *caused* its\n  evaluation in the first place. Note that this does neither have to\n  be the block that called it, nor even the dominator if you put it as\n  a graph problem. Therefore we need more information, which the context\n  nodes provide.\n\n* Contexts are declared \"forward\": We insert the CmmContext node into\n  the parent block, declaring itself context of the labelled other block.\n  This means that if blocks are merged we have to make no corrections:\n  The result block will become the context of the blocks referenced from\n  either source block. On the other hand, eliminating blocks might now\n  leave superflous CmmContext nodes behind.\n\n* We must also take care to not copy or duplicate CmmContext nodes.\n  We especially can't declare them as okToDuplicate in CmmContFlowOpt,\n  which sadly yields less optimal code, even though I think most of it\n  gets fixed in the NCG.\n\n* Finally, the context relationships can and will refer to blocks in\n  other procedures - and I think it's not even guaranteed that we only\n  reference entry blocks. This requires back-ends to consider whole\n  Cmm groups when putting the context tree together.","Peter Wortmann",true],["0c041be8e220c5fe7e04f3c60429c316210d0f25","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Emit ticks before heap check\n\nThis makes sure that we get the ticks in entry blocks, and properly cover\nthe cost of the heap check. This is generally the right thing to do as\nlong as the tick in question doesn't track entry counts: Those would be\nwrong due to re-execution of the entry block after a failed heap check.","Peter Wortmann",true],["2d96fccee5193f025765b2d662679402e2799d58","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Add Sp unwind information to Cmm\n\nThis is meant as a tool for the debugger to determine past values of\nregisters, most critically the stack pointer Sp.\n\n* We declare yet another new constructor for CmmNode - and this time\n  there's actually little choice, as unwind information can and will\n  change mid-block. We don't actually make use of these capabilities,\n  and back-end support would be tricky (generate new labels?), but it\n  feels like the right way to do it.\n\n* Even though we only use it for Sp so far, we allow CmmUnwind to specify\n  unwind information for any register. This is pretty cheap and could\n  come in useful in future.\n\n* We allow full CmmExpr expressions for specifying unwind values. The\n  advantage here is that we don't have to make up new syntax, and can e.g.\n  use the WDS macro directly. On the other hand, the back-end will now\n  have to simplify the expression until it can sensibly be converted\n  into DWARF byte code - a process which might fail, yielding NCG panics.\n  On the other hand, when you're writing Cmm by hand you really ought to\n  know what you're doing.","Peter Wortmann",true],["bc254057b17b791766b1a2ad3d4c185aeba05696","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Debug data extraction (NCG support)\n\nThe new Debug module handles collection all the pieces of debug\ninformation we need for debug information. We organise them as a tree\nso it is easy to follow context relations. We also implement the\nplumbing needed to collect them for the native code generator.\n\nNotes:\n\n* Context trees are checked for some sanity rules here, so we notice\n  early if CodeGen messed up.\n\n* We are careful to not be too lazy so we don't end up breaking streaming.\n  Debug data will be kept alive until the end of codegen, after all.\n\n* We change native assembler dumps to happen right away for every Cmm group.\n  This simplifies the code somewhat and is consistent with how pretty much\n  all of GHC handles dumps with  respect to streamed code.","Peter Wortmann",true],["837f885f049e791ab03089783983b80fe52b6341","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Generate .loc/.file directives from source ticks\n\nThis generates DWARF, albeit indirectly using the assembler. This is\nthe easiest (and, apparently, quite standard) method of generating the\n.debug_line DWARF section.\n\nNotes:\n\n* Note we have to make sure that .file directives appear correctly\n  before the respective .loc. Right now we ppr them manually, which makes\n  them absent from dumps. Fixing this would require .file to become a\n  native instruction.\n\n* We have to pass a lot of things around the native code generator. I\n  know Ian did quite a bit of refactoring already, but having one common\n  monad could *really* simplify things here...\n\n* To support SplitObjcs, we need to emit/reset all DWARF data at every\n  split. We use the occassion to move split marker generation to\n  cmmNativeGenStream as well, so debug data extraction doesn't have to\n  choke on it.\n\nConflicts:\n\tcompiler/nativeGen/AsmCodeGen.lhs","Peter Wortmann",true],["33397b9b67f629b6b595f6d2624e03d9e9a7d0e1","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Generate DWARF info section\n\nThis is where we actually make GHC emit DWARF code. The info section\ncontains all the general meta information bits as well as an entry for\nevery block of native code.\n\nNotes:\n\n* We need quite a few new labels in order to properly address starts\n  and ends of blocks.w1\n\n* There is no DWARF language ID for Haskell, so we arbitrarily choose a\n  number derived from dW_LANG_lo_user and 'hs'. This feels like the right\n  thing to do, even though sometimes DWARF tools get confused by any\n  unknown value in this field.","Peter Wortmann",true],["3e04914c7ea38826f61253ce03a19888ee64c664","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Generate DWARF unwind information\n\nThis is telling debuggers such as GDB how to \"unwind\" a program state,\nwhich allows them to walk the stack up.\n\nNotes:\n\n* The code is quite general, perhaps unnecessarily so. Unless we get more\n  unwind information, only the first case of pprSetUnwind will get used -\n  and pprUnwindExpr and pprUndefUnwind will never be called. It just so\n  happens that this is a point where we can get a lot of features\n  cheaply, even if we don't use them.\n\n* When determining what location to show for a return address, most\n  debuggers check the map for \"rip-1\", assuming that's where the \"call\"\n  instruction is. For tables-next-to-code, that happens to always\n  be the end of an info table. We therefore cheat a bit here by shifting\n  .debug_frame information so it covers the end of the info table, as\n  well as generating a .loc directive for the info table data.\n\n  Debuggers will still show the wrong label for the return address, though.\n  Haven't found a way around that one yet.","Peter Wortmann",true],["bfbe066d5193f1c99e76266ce92c5171902c794e","5aed822d10922bb164e7b702cd8d94f3cb680fc0@leeds.ac.uk","Save full debug structures into GHC-specific section\n\nThe conversion to DWARF is always lossy, so instead we put all the extra\nbits of information into an extra object file section (.debug-ghc).\n\nNotes:\n\n* We use the eventlog format. This might seem like a slightly arbitrary\n  choice, but makes it easy to copy debug data into eventlogs later in\n  order to do profiling. In the meantime, it's well-defined and extensible,\n  so until we run out of record IDs there's no strong reason against it\n  either.\n\n* Core notes now cause the complete Core to be copied. We are reasonably\n  smart about this: We never emit a piece of Core twice, and use a compact\n  binary representation for most Core constructors.\n\n  On the other hand, we just pretty-print types as well as names and emit\n  them as strings. This can sometimes lead to packets becoming too large\n  for the eventlog format to handle (we had types break the 20k loc mark).\n  In order to not run into these kinds of problems, we just omit packets\n  that are longer than a certain threshold.\n\n* The amount of data generated here is significant. We therefore use faily\n  low-level generation code using memory buffers. Furthermore, we include\n  the data as a string, escaped using another well-optimized low-level\n  routine. All this might make it hard to read debug data in the assembly,\n  but is absolutely required for debugging not to become a significant\n  resource hog.\n\n* The eventlog IDs used here were chosen primarily to avoid collisions.\n  If this code gets merged they should be adjusted appropriately.","Peter Wortmann",true]],"size":15,"ref":"refs/heads/profiling-import","head":"bfbe066d5193f1c99e76266ce92c5171902c794e"}