-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher Li wrote: [...] > OK, if it is just for OP_LOAD. Will this attached patch solve your problem? > > Instead of adding type to every instruction. It just add that for the OP_LOAD > instruction in insn->orig_type. If that works for you. I am very glad to reclaim > the space back on instruction structure. Sorry, I'm not at home right now and can't test this (and probably won't until New Year, though I'll have a go). Also, I don't know if it *is* just of OP_LOAD. That's just the one I remember from looking back at old email. I think the issue is that OP_LOAD breaks the chain of pseudo->definer->pseudo->definer that I was using to determine the intrinsic type of the pseudo, but there may be other instructions that do this as well. I'd imagine that nobody else has come across this yet because most people are happy using the size to distinguish between different types; but (assuming that I've remembered this correctly) this'll bite anyone who needs to distinguish floats from int32s of doubles from int64s. If space is really an issue, would it make sense therefore to replace the insn->size (and symbol->size etc) field with a ->type field pointing at the defining symbol for the type? Anyone who needs the type can get it from the defining symbol, plus all the other information that people like me need would be available, and may also simplify other code. (I could throw away a complete source file!) > I think sparse should do the proper cast for you when you call > the function call. If it does not, that is a bug and we can fix it. Okay, at some point I'll try to come up with a proper use case. - -- David Given dg@xxxxxxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJUr9Mf9E0noFvlzgRAmWCAJ4+Q+XPPn9stf8TWHUiIrAk3kwcTACgtJbd mVD5E9Cg6a2tOtiTI34Mcz8= =FrsN -----END PGP SIGNATURE----- -- 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
