From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68849 invoked by alias); 15 Jun 2015 21:15:17 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 68796 invoked by uid 89); 15 Jun 2015 21:15:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Message-ID: <1434402461.14663.28.camel@surprise> Subject: Re: Hit a showstopper issue From: David Malcolm To: Dibyendu Majumdar Cc: jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: <1434401660.14663.27.camel@surprise> References: <1434329514.3192.28.camel@surprise> <1434401660.14663.27.camel@surprise> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-SW-Source: 2015-q2/txt/msg00076.txt.bz2 On Mon, 2015-06-15 at 16:54 -0400, David Malcolm wrote: > On Mon, 2015-06-15 at 21:25 +0100, Dibyendu Majumdar wrote: > > On 15 June 2015 at 20:32, Dibyendu Majumdar wrote: > > > I apologize for bringing in LLVM comparison again - but they have a > > > model that seems to work just right. Basically the LLVM > > > verifier/compiler will detect invalid blocks and conrol flow - which > > > is more important for debugging purposes. Usually a bug will manifest > > > itself in some corruption in the control flow - e.g. variable not > > > accessible in all code paths and such - LLVM detects these and raises > > > errors. > > > > Of course LLVM's IR is SSA form so that probably makes it easier to > > validate the control flow. They described this as 'well formed'-ness - > > the verifier detects if the code is well-formed and complains if 'the > > definition of %x does not dominate all of its uses'. My understanding > > is that the IR you are working with is not SSA-form so this type of > > validation may not be possible... > > Yes: the IR exposed by the libgccjit API is not SSA-form. The optimizer > does use SSA-form internally. > > I think my opinion at the time was that forcing users to create phi > nodes was unnecessary work for them; let the API do it automatically, > internally. I don't know if the loss of this kind of validation is a > show-stopper; it feels to me more like a fussy API that the user has to > do extra work to appease. But I could be wrong. > > > In any case a warning about unreachable bocks may be more appropriate > > than errors. > > FWIW I've experimented in the past with turning on warnings about > uninitialized vars, so maybe we need an API setting for validations, > with each validation having a tri-state: > * perform validation, as error > * perform validate, as warnings to stderr > * don't validate > > (thinking aloud here) I've filed a bug about the lack of a way to turn off the unreachable block checking, as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546