On Thu, Mar 16, 2017 at 2:19 PM, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> Just to be sure of what you're suggesting, you mean that code like:
> int foo(int a)
> {
> printf("%d %d", a, 123);
> }
>
> Would be linearized as something like:
> foo:
> <entry-point>
> set.64 %r1 <- "%d %d"
> arg.64 %r2 <- %r1
> arg.32 %r3 <- %arg1
> arg.32 %r4 <- %123
> call.32 %r5 <- printf, %r2, %r3, %r4
>
> with the %r2, %r3, %r4 in the call identifying their defining
> instructions and the size of these OP_ARG instruction being,
> of course, defined at linearization time with the type
> of the corresponding expression?
Close. I was thinking that the "OP_ARG" instructions wouldn't really
generate any pseudo's, they'd just consume them (like the OP_CALL does
now).
So taking your example, which currently linearizes as
foo:
call.32 %r3 <- printf, "%d %d", %arg1, $123
ret.32 %r3
I was more thinking that you'd linearize it purely as a split of the
OP_CALL into "OP_ARG* + OP_CALL":
foo:
arg.64 "%d %d"
arg.32 %arg1
arg.32 $123
call.32 %r3 <- printf
ret.32 %r3
where the OP_ARG would act kind of like a OP_SETVAL instruction, but
it wouldn't have a target pseudo (the target is the "call" instruction
that follows).
Now, an alternative would be that we *do* give it a pseudo target, but
not a regular one, but an "outgoing argument" one. We currently have
those PSEUDO_ARG pseudos that are for incoming arguments, and we could
split that into PSEUDO_ARG_IN and PSEUDO_ARG_OUT.
I dunno. My mental model was to just always have the OP_ARG
instructions tie very closely to the OP_CALL that they are associated
with.
Linus
--
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
