Linus Torvalds explains: On Mon, Aug 29, 2011 at 12:45 PM, Pekka Enberg <penberg@kernel.org> wrote: > However, i'm not 100% sure that's sufficient. Is OP_CAST always zero-extend > or do we need to check for something specific here? OP_CAST is always a zero-extend, OP_SCAST is a sign-extending one. (Of course, they may be *truncating* casts too, which don't need to generate any code on most architectures). OP_PTRCAST should act as OP_CAST. NOTE! The casting is dubious. We only have a single OP_FPCAST, for example, and that's just broken. Right now "OP_FPCAST" means that the *source* was a FP value. But if we cast *to* a FP value, it ends up showing up as OP_[S]CAST, which is just bogus. The FPCAST should be for any FP operation (to or from or both), and then the FPCAST logic would have to decide how it handles it. The FP support in general is pretty weak. The kernel doesn't do FP, I never really cared about it. This patch fixes comparison operator code generation. For example, this C code int sete(int x, int y) { return x == y; } is translated as follows: Before: 0000000000000000 <sete>: 0: 31 c9 xor %ecx,%ecx 2: 39 f7 cmp %esi,%edi 4: b8 ff ff ff ff mov $0xffffffff,%eax 9: 0f 45 c1 cmovne %ecx,%eax c: c3 retq After: 0000000000000000 <sete>: 0: 39 f7 cmp %esi,%edi 2: 0f 94 c0 sete %al 5: 0f b6 c0 movzbl %al,%eax 8: c3 retq Signed-off-by: Pekka Enberg <penberg@kernel.org>