On Fri, 2005-11-18 at 09:29, Bernd Schmidt wrote: > > Also, please keep in mind that generating and then assembling debug > > info takes a huge amount of I/O relative to code size. I'd expect much > > more than 1% saving the write-out and write-in on -g. > > So, maybe a simpler strategy could be to make minor modifications to gas > and gcc so that the former is linked in and the latter can pass strings > to it? Maybe that could get us a performance improvement without the > need for a massive overhaul of all backends, and the need to duplicate > object code generation.
That's surprisingly close to how I'd see a migration strategy working anyway. Firstly we have to retain permanent access to the assembler's parser to handle inline asm statements. However, we don't have to use the parsing stage within the guts of the compiler. So I see a migration strategy something as follows: - Create a more complete set of output routines for printing assembly (ultimately a backend should never write to asm_out_file but to the new routines -- we're probably 90%+ towards that goal already). A back-end can't convert to embedded assembly until that process is complete. - once that's done we can start integrating the assembler code, the first step would be to feed the standard parser directly from the new assembly output routines (probably a line, or a statement at a time). - Then, incrementally, we can bypass the parse layer to call routines directly in the assembler. This can be done both for directives and for assembly of instructions. *but it can all be done incrementally*. The main difficulty is preserving -S output in a converted target if that is requested. It ought to be possible but it will need some care. R.
