On Tue, Jun 14, 2005 at 10:08:16PM -0700, Richard Henderson wrote: > I suspect that one could get quite a lot of milage out of parsing > the assembly code and turning most of it into straight GIMPLE, rather > than into ASM_EXPRs. A great many examples of VC++ inline asms that > I've seen were completely and utterly trivial; the compiler could have > done a better job. Of course there will be cases that you either > can't understand, or use instructions that don't map to an EXPR or a > builtin. But I expect that more often than not, you can reduce the > inline asm block to one such insn, and expose all the rest of the > data movement to the compiler.
My previous employer (Metrowerks) did this when parsing GCC style asm instructions, and it caused lots of complaints from users. The main complaint is users did not want the compiler mucking about with their precious hand scheduled insns, and made it much harder to debug. Another problem is when things like status registers or flags fields aren't adequately handled by the compiler. For example on the x86, if you change the rounding mode, we currently don't have a (USE) of the flags field, so the compiler doesn't know that it can't move the set rounding mode instruction before other floating point instructions. Obviously, the right solution is the encode all of this hidden state information into the RTL, GIMPLE, etc. but it is a large and mind numbing process. Finally, for the x86/x86_64, there are a lot of instructions that need to be handled, and it is an ongoing maintenance problem in that you now need to modify GCC as well as binutils to add new instructions. -- Michael Meissner email: [EMAIL PROTECTED]
