Visual C++ style inline asms

[Mike Stump]

On Tuesday, June 14, 2005, at 10:08  PM, Richard Henderson wrote:
>> Didn't RTH objected the last time?
>
> One has to do a less gross job of it than Red Hat did.

I did go back and re-reread all the useful content you, and others 
gave.  I did expect that all past concerns raised remain and that we'd 
be expected to find some `reasonable' way to address all those, and all 
the ones that would come up during the development of the feature.  You 
and Mark I think raised the highest bars, but I remain hopeful that 
there is a solution that is low enough impact in other areas of the 
compiler, and yet adds the required functionality.  I think the CW asms 
stuff was a good learning experience for us.

> I suppose I could be prodded into pulling out the code

I don't want to so prode you right now.  If/when we start up a project 
to do it, I'd be interested in things like testsuite (testcases) and 
the description for how the parser was wired in for C++, if you liked 
the way it was done, as our CW version feels too duplicative and more 
invasive than ultimate I think I'd like.

> 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.

Yeah, been there, done that.  Ultimately, I sure we'd miss some 
important bits in the first couple of versions, but as people pumped 
code through it, we'd get them in.  I am not confident that I could get 
enough help (enough testcases) fast enough to have it all done in the 
first stage.

> 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.

Ultimately, one just has to slowly and carefully describe it for the 
optimizer, in the existing language the optimizer uses.  The CW asms 
were done using use ASM_EXPRs, and we got a lot of milage out of that 
route. Fundamentally, if other constructs are a better match, it would 
be better to use them.  Take for example a __builtin_opcode_blabla and 
blabla r1, r2, n1, instead of generating asm ("blabla .... ), we'd call 
__builtin_opcode_blabla (r1, r2, n1), and then let it generate what 
ever it does.  If all instruction had  a gen_blabla () or 
__builtin_opcode_blabla(), trivially, one would avoid any ASM_EXPRs and 
just use them all.  The advantage to that style is then the optimizer 
can know what is going on, and that ultimately, I think is required.  
Also, I can see how to wire that style of support into the compiler 
cleanly.  The CW support didn't require invasive changes to the 
optimizer.  I'm hoping the worse case scenario for x86 support would be 
the i387 fp stack and the carry flags and other status bits, and not 
something like reload.

> 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,

Yes, this is the direction I'd want to do.

Just so others have an idea of how invasive it might be, the CW asm are 
strapped in with 67 multiline hunks, and 33 single line changes.  I'd 
hope/expect that MS asms would similar.