On Wed, Aug 9, 2017 at 1:41 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > > When assigning values to bitfields I have noticed that some times > Sparse generates a CAST instruction with an odd bit size - i.e. not a > standard integer size. I was wondering if there are specific scenarios > that lead to this. While LLVM handles the odd cast - I am working with > another backend (Nanojit) that doesn't. The cast instructions are a bit odd, I agree. The basic rule is that each pseudo has a type (signed int, unsigned int, fp, ptr) and a size (which is whatever, although obviously pointers and FP values are fairly constrained). NOTE! By "type" above, I mean "value type". There's another kind of "type" when it comes to pseudos, ie the "pseudo->type" thing, which is reg/sym/val/arg/phi. That's a different thing entirely. Anyway, the size and value type of a pseudo is defined by the size of the instruction that defines it. And whenever the type or size changes, there should be a cast instruction. But honestly, the casts are not very well done. The size change should always be fairly obvious: you can see the old size by looking at the size of the defining instruction of the source pseudo, and you can see the new size by looking at the size of the cast instruction that defines the new pseudo. But the "value type" change is pretty garbage. We have four "ops" (CAST/SCAST/PTRCAST/FPCAST), but they make absolutely no sense. The problem is that there really are many many different combinations (unsigned integer to floating point, Fp to ptr, etc etc), and the opcode is generated from some random combination of source/dst that really doesn't make sense. I'm not proud of it. It probably really should be just one cast op, and then the type should be something that - like the size - is something you go look up. And *when* the source and destination are both integers (and arguably a pointer too), then obviously the cast can just always be turned into a zero-extension or sign extension. So the OP_*CAST functions really are a bit confused. Maybe Luc has cleaned some of it up already, I'm going partly from memory. To make a long story short: the OP_*CAST stuff is not great, and doesn't make a ton of sense. It should probably be rewritten. 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