On Thu, Mar 16, 2017 at 01:43:05PM -0700, Linus Torvalds wrote:
> On Thu, Mar 16, 2017 at 1:19 PM, Dibyendu Majumdar
> <mobile@xxxxxxxxxxxxxxx> wrote:
> >
> > The issue is not with the type of %r6 but %arg3 and %arg4 if these
> > happen to be integer constants, and the function is variadic so we
> > cannot work out the type from the function prototype.
>
> Yes. Ok, I see the problem.
>
> I think we could add a 'size' to the pseudo, and solve it that way.
> CSE and other linearization artifacts may mean that the type is
> undefined, but the size should be well-defined.
>
> Alternatively - and this might be the better solution - the OP_CALL
> instruction might be better off split up a bit. Instead of having just
> that
>
> struct pseudo_list *arguments;
>
> that lists the arguments, maybe it should have a
>
> struct instruction_list *arguments;
>
> with a new OP_ARG instruction to generate the argument.
>
> That way all the arguments would have a size, and always a generating
> instruction.
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?
-- 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
