On Fri, Aug 11, 2017 at 11:28:23AM +0100, Dibyendu Majumdar wrote: > Hi Luc, > > On 10 August 2017 at 23:34, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > * the OP_PUSH instructions do a perfect job of giving a type to functions > > arguments > > * the OP_PUSH instructions also nicely abstract away the *operation* of > > argument passing that all architectures have. It's a good thing. > > > > It is true that OP_PUSH instructions resolved the issue I was having. > However there is something odd about them as they are not really > instructions in the instruction stream, are they? They get added as > arguments to the OP_CALL instruction. The solution works great though. Yes, they are somehow odd. I'm not totally sure by what you exactly mean by "in the instruction stream", though. Let's use an example: fun(1, a) Currently it's linearized as: call fun, 1, a The first version of the patch gave: arg %r1, $1 arg %r2, a call fun, %r1, %r2 The current version gives: push $1 push a call fun which is very much like a lot of functions really work. And yes, the 'pushes' is somehow disocciated from the 'call', or the 'call' is not a consumer of the 'pushes'. It's the stack that is the consumer from those 'pushes' and the 'call' (or more exactly the function 'fun') that is the consumer of (what have been pushed on) the stack. The 'args' were really only a 'move' or 'copy' in disguise, they are not needed at this level (but OK they *also* gave the type). The 'pushes' are IMO the right thing needed here. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
