From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Enberg Subject: Re: LLVM and PSEUDO_REG/PSEUDO_PHI Date: Mon, 29 Aug 2011 23:42:37 +0300 Message-ID: References: <4E5495C9.6050207@kernel.org> <4E55F33C.50203@kernel.org> <4E573A3E.6060104@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from mail-iy0-f174.google.com ([209.85.210.174]:37783 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754038Ab1H2Umi (ORCPT ); Mon, 29 Aug 2011 16:42:38 -0400 Received: by iabu26 with SMTP id u26so820848iab.19 for ; Mon, 29 Aug 2011 13:42:38 -0700 (PDT) In-Reply-To: Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Linus Torvalds Cc: Jeff Garzik , linux-sparse@vger.kernel.org On Mon, Aug 29, 2011 at 12:45 PM, Pekka Enberg 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? On Mon, Aug 29, 2011 at 11:32 PM, Linus Torvalds wrote: > 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. OK, makes perfect sense. We don't support OP_SCAST or OP_PTRCAST yet so those should be fine. I fixed OP_CAST like this: https://github.com/penberg/sparse-llvm/commit/2dea6f7fb07cd18255cf1d73079638dc96bdd08b So comparison operators should be OK now. On Mon, Aug 29, 2011 at 11:32 PM, Linus Torvalds wrote: > 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. Good to know. I've added support for simple FP ops though and they seem to be fine. Pekka