On Wed, Feb 1, 2012 at 1:55 AM, Pekka Enberg <penberg@xxxxxxxxxx> wrote:
> From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>
> On Tue, Aug 30, 2011 at 10:43 AM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
>> * if someone knows how to access a function declaration, I can solve the
>> varargs problem
>
> Hmm. Right now we do not have access to the function declaration at
> linearize time. We've checked that the arguments match, and we've cast
> the arguments to the right types (evaluate.c), so the thinking was
> that you just use the arguments as-is.
Ok, this patch definitely works. However, I think there is ways to get the
type without this patch. The more general question is, how to get type of
any given pseudo register. Currently it is a bit twisted but that information
should be accessible. I believe that has been discuss on the mail list
before. That is why we have insn->type. LLVM want to know every type
of every value in the back end any way. If we are going to do proper
llvm style "get element pointer" in the back end, we need to access type
of every pesudo register.
The current twisted way to get type from the pseudo register is some thing like
this (totally untested code):
swtich (pseudo->type) {
case PSEDUO_REG:
return pseudo->def->type;
case PSEUDO_ARG:
case PSEUDO_SYMBOL:
return psuedo->symbol;
....
}
Now think about it for a little bit, instead of this patch, how about
I make a counter RFC:
Move the insn->type into pseudo->type. Then you can use use
pseudo->type to access
the type of any pseudo. I estimate the memory usage should be similar,
if not smaller.
It make the pesudo struct larger, however, it make the insn struct
smaller. There is more
instruction than pesudo register in general, because not all
instruction resulting an output
pesudo register. Even consider some pseudo does not generate from
instructions, it is
likely a saving in memory foot print overall.
The plus side, you can have easy access of type for all pseudo. We
might able to get
rid of insn->size as well. Over all I feel it is cleaner.
Suggestions and feed back please?
Chris
--
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
