On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote: > On Jun 14, 2005, at 9:25 PM, Mike Stump wrote: > >Any objections to adding Visual C++ style inline asms? > > Didn't RTH objected the last time?
One has to do a less gross job of it than Red Hat did. I suppose I could be prodded into pulling out the code so that you can see where the bar is. You'll need and EXTREMELY large testsuite. You'll find that the MS documentation is useless, and you'll have to deduce the desired semantics from customer code bases. Presumably Apple can find large customers who will want this kind of thing and can arrange to code exchanges in some way, if only NDA. But if NDA, I expect reduced test cases to make their way into our testsuite. Expect to want to implement "naked" functions as well, because MS does, and quite a lot of VC++ inline asm code expects to use them. Expect me to barf on your shoes. I don't recall if Darwin uses %ebx for pic code like ELF. If you do, expect to find that lots of user code expects to be able to clobber it, because Windows doesn't do pic code at all, and so reserves no such register. 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. r~
