From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luc Van Oostenryck Subject: Re: Sparse-LLVM issue compiling NULL pointers Date: Thu, 2 Mar 2017 14:56:55 +0100 Message-ID: <20170302135655.s742zcslis5r56if@macpro.local> References: <20170228150956.moyfiyd5zf7tbeze@macbook.local> <20170302052124.fsqogvysufayy4to@macbook.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-wm0-f42.google.com ([74.125.82.42]:37759 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751600AbdCBOHE (ORCPT ); Thu, 2 Mar 2017 09:07:04 -0500 Received: by mail-wm0-f42.google.com with SMTP id n11so25838034wma.0 for ; Thu, 02 Mar 2017 06:06:14 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Dibyendu Majumdar Cc: Linux-Sparse On Thu, Mar 02, 2017 at 05:41:59AM +0000, Dibyendu Majumdar wrote: > On 2 March 2017 at 05:21, Luc Van Oostenryck > wrote: > >> Anyway have hit a bunch of other issues with sparse-llvm ... :-( > > > > Each day its problem (and happily its solution too!). > > > > I will submit test cases for the new problems when I get some time. OK. Thanks. > But I am beginning to think that there is quite a bit of work needed > to fix the issues, and in any case it might be better to create an > LLVM backend from the parse tree rather than the linearized version. Possible, but this will certainly need some work too. > The current approach is very low level - for example struct member > access bypasses the natural LLVM way of doing it. Yes, that's true. > This approach will > have the consequence that LLVM will generate poor quality code as it > will not have enough information to optimise properly. The current > approach is more suited to backends that directly emit machine code I > think. As far as I understood, the idea behind the linearized code and the optimization made on it was to have it's own backend. Sparse-llvm only came much later. Regards, Luc