On Jun 8, 2009, Diego Novillo <dnovi...@google.com> wrote: > - Performance differences over SPEC2006 and the other benchmarks > we keep track of.
This one is trivial: none whatsoever. The generated code is the same, and it *must* be the same. Debug information must never change the generated code, and VTA is all about debug information. There's a lot of infrastructure to ensure that code remains the unchanged, and -fcompare-debug testing backs this up. It doesn't make much sense to run the same code twice to verify that it performs the same, does it? :-) > Do all these comparisons against mainline as of the last merge > point. I'll start performing the other measurements you requested. Please be patient, it will take some time until I figure out how to use the scripts you pointed at me and locate the code bases. For the measurements, I won't use the last merge, but rather the trunk (in which most of the infrastructure patches were already installed, with minor changes) vs trunk+the posted patchset. Or maybe I'll do another merge into the branch, so that we have exact revisions in the SVN tree to refer to. I hope you don't mind that I make the tests in a slightly different tree (it's easier for me, and shouldn't make any difference for you), but if you insist, I'll do exactly what you suggested. > I would like to have a set of criteria or guidelines of what should a > pass writer keep in mind to make sure that their transformations do > not butcher debug information. I've already written about this. Butchering debug information with this design is very hard. Basically, you have to work very hard to break it, because it's designed so that, unless you actively stop transformations that are made to executable code from also applying to debug annotations, you'll keep it up to date and correct. What needs to be taken care of is something else: avoiding codegen differences. This means that whatever factors you use to make decisions on whether or not to make a transformation shouldn't take debug annotations into account. E.g., if you count how many references there are to a certain DEF, don't take the debug USEs into account. If you count how many STMTs there are in a function or block to decide whether to inline it or duplicate it, don't count the annotations. And then, in the cases in which an transformation is made when there is only one (non-debug) reference to a name, it is probably useful to update any debug insns that refer to that name. If you don't, debug info will be less complete, but still correct, at least in SSA land. In post-reload RTL it's more important to fix these things up, otherwise you might end up with incorrect debug info. That's all. Doesn't sound that bad, does it? > From what I understand, there are two situations > that need handling: > - When doing analysis, passes should explicitly ignore certain > artifacts that carry debugging info. Yup. This is where most of the few changes go. If you fail to do that where you should, you get -fcompare-debug errors or slightly different code. > - When applying transformations, passes should > generate/move/modify those artifacts. Only in very rare circumstances (1- or 0- refs special cases) do they need special attention. In nearly all cases, because of their nature, they're correctly updated just like the optimizer would have to do to any other piece of code. > Documentation should describe exactly what those artifacts are > and how should they be handled. Are the 3 paragraphs above clear enough? When in the documentation do you suggest this should go? > - What percentage of code in a pass is dedicated exclusively to > handling debug info? In nearly all of the tree passes, it's one or two lines per file, if it's that much. In RTL it's sometimes a bit more than that. > - What is the point of diminishing returns? If I write 30% more > to keep track of debug info, will the debug info get 30% > better? See below. > - What does it mean for debug info to be 30% better? How do > we measure 'debug info goodness'? I don't know how to measure “30% better” debug info. Do you have a criterion to suggest? I see at least two dimensions for measuring debug info improvements: correctness and completeness. Currently we suck at both. VTA's design is such that the infrastructure work I've done over its development addresses teh correctness problem once and for all. The remaining improvements are in completeness, and those are going to be (i) in the var-tracking pass and debug info emitters, that still can't or don't know how to use all the information that reaches them, and (ii) in passes that currently discard or invalidate debug annotations (so that variables end up marked as optimized out), but that could retain it with a bit of additional work. I don't have any actual examples of (ii), I'm only aware of their theoretical possibility, so I can't quantify additional work required for that. That said, the additional work would be explicitly optional, and certainly not necessarily taken up by the maintainer of the pass, but rather by someone interested in debug information. > - Does keeping debug info up-to-date introduce algorithmic > changes to the pass? For passes that make changes regardless of how many references there are to names, no changes whatsoever are required. Debug annotations will be updated just like any other pieces of code. For passes that make changes for boundary cases (say 1 or 0 references), it is useful (but only mandatory post reload) to modify the algorithm to also update any other debug stmts/insns that refer to the modified item. > Clearly, if one needs to dedicate a large portion of the pass > just to handle debug information, that is going to be a very hard > sell. Agreed. That's why it was designed to be absolutely trivial. All the -fcompare-debug debugging strongly supports that it is so. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
