Christopher Li wrote: [...]
I agree we should probability make the ctype into instruction so make the back end easier.
That would be nice; in order to find the type of a pseudo that resulted from an instruction, I have to recurse back through *that* instructions' operands. This seems rather heavyweight.
In fact, because I need to associate a fair bit of data with each pseudo, I then cache the type information in the pseudo's user data structure, which for now is stored in an AVL tree keyed of the pseudo's address (there is no overkill; there is only 'open fire!' and 'reload!'). May I put in a request for a user field on every sparse data structure, for doing this sort of thing, please?
Which brings me to my next question: while I'm now successfully compiling some code, including loops, I'm having trouble with other code. In particular, it would appear that now and again a bb will export a pseudo using one storage, and another bb will import the same pseudo but using a *different* storage. This is making it rather hard for me to correctly wire up the interconnects between basic blocks. Currently I'm working around this using data stored in my user data structure described above, but I suspect there's another thing here I'm not getting. What's the recommended strategy here?
(Incidentally, thanks for the help you've been giving me; it's been aiding me substantially.)
-- David Given dg@xxxxxxxxxxx -- 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
