On Tue, Aug 25, 2009 at 6:30 PM, Gabriel Michael Black<[email protected]> wrote: >> >> Actually I was hoping that you wouldn't have to include all the .hh >> files. If the main decoder in main_decoder.cc calls out to a >> subdecoder for x87 ops in x87_decoder.cc, then a header that declares >> the instruction objects for x87 instructions would only need to be >> included in the latter .cc file. > > That's true, but then we may have function call overhead at those points > since I don't know if gcc does cross object module inlining. If the header > files prove to be a major contributor then that may still be worth it.
Yes, you'd pay for the function call, but that shouldn't be too noticeable, particularly if we cache decoded instructions. (Does x86 use the decode cache or did you have to disable it b/c it didn't deal with variable length instructions?) >> If we don't care that they're >> actually inlined (and certainly for the generateDisassembly methods at >> least we shouldn't), then it should be trivial to define them outside >> the class declaration dump them in a separately compiled .cc file. We >> could even do something very basic like call a method for outputting >> these definitions, and have that method transparently track the number >> of lines its generated, then just start a new file whenever that >> number gets above some threshold. So we'd end up with >> decoder_methods1.cc, decoder_methods2.cc, etc. You'd still probably >> have to include all the declarations in a single .hh that gets >> included everywhere, since there are going to be inheritance >> relationships that we won't be tracking, but if your theory that the >> declarations are not the problem is true, that won't matter. > > That would work mostly I think. You'd have to be careful you didn't split > something in half, and also that any static functions are available > everywhere. I don't remember off hand if I used any of those so it might be > a moot point. I assumed that the method that did this would be called with entire functions, so as long as it only split files at the start or end of a call then you wouldn't split anything. > >> >> It might be a little tricky to get scons to figure out how many >> decoder_methodsN.cc files there are to compile, though. I'm sure Nate >> can figure something out :-). >> >> Seems like the first step is to verify where the compilation >> bottleneck really is so that we know which of these approaches might >> actually solve the problem... > > Yes. I'm not sure how to do that. Probably the easiest way would just be to take a current decoder.cc, hack it up manually to match one of the thigns we're proposing, then invoke gcc manually on the result and time it. (Not necessarily easy in an absolute sense, but it's just a one-off try so there's no point in doing anything more automated IMO.) Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
