On Wed, 3 Aug 2011, Ulrich Weigand wrote: > Richard Guenther wrote: > > asm ("scall" : : "asm("r0")" (10), ...) > Maybe it would be possible to implement this while keeping the syntax > of existing code by (re-)defining the semantics of register asm to > basically say that: > > If a variable X is declared as register asm for register Y, and X > is later on used as operand to an inline asm, the register allocator > will choose register Y to hold that asm operand.
"me too": Nice idea! > (And this is the > full specification of register asm semantics, nothing beyond this > is guaranteed.) You'd have to handle global registers differently, and local fixed registers not feeding into asms. For everything else, error or warning. That should be ok, because local asm registers are wonderfully already documented to have that restriction: "Local register variables in specific registers do not reserve the registers, except at the point where they are used as input or output operands in an @code{asm} statement and the @code{asm} statement itself is not deleted." So, it's just a small matter of programming to make that happen for real. :-) To make sure, it'd be nice if someone could perhaps grep an entire GNU/Linux-or-other distribution including the kernel for uses of asm-declared *local* registers that don't directly feed into asms and not being the stack-pointer? Or can we get away with just saying that local asm registers haven't had any other documented meaning for the last seven years? > It seems this semantics could be implemented very early on, probably > in the frontend itself. The frontend would mark the *asm* statement > as using the specified register (there would be no special handling > of the *variable* as such, after the frontend is done). The optimizers > would then simply be required to pass the asm-statement register > annotations though, much like today they pass constraints through. > At the point where register allocation decisions are made, those > register annotations would then be acted on. People ask why it's not already like that, probably because they assume the ideal sequence of events. At least the quote above is a late addition (close to seven years now). IIUC, asms and register asms weren't originally tied together and the current implementation with early register tying just happened to work well together, well, that is until the SSA revolution. ;) brgds, H-P