From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47065 invoked by alias); 16 Jun 2015 18:48:33 -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 47053 invoked by uid 89); 16 Jun 2015 18:48:32 -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=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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: <1434480061.14663.47.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: 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.22 X-SW-Source: 2015-q2/txt/msg00083.txt.bz2 On Mon, 2015-06-15 at 22:18 +0100, Dibyendu Majumdar wrote: > On 15 June 2015 at 21:54, David Malcolm wrote: > > 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 LLVM I hardly ever specify phi-nodes - it constructs them during > optimization when it detects a scenario requiring a phi-node. I just > declare my locals and use them appropriately - but yes one can > explicitly code phi-nodes and to me (who is not so familiar with the > concept) this is painful. > > >> 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 I'm thinking of something like this: enum gcc_jit_validation_check { GCC_JIT_VALIDATION_CHECK_UNREACHABLE_BLOCKS, GCC_JIT_VALIDATION_CHECK_UNINITIALIZED_LOCALS, GCC_JIT_NUM_VALIDATION_CHECKS }; enum gcc_jit_validation_response { GCC_JIT_VALIDATION_IGNORE, GCC_JIT_VALIDATION_LOG_TO_STDERR, GCC_JIT_VALIDATION_ERROR, GCC_JIT_NUM_VALIDATION_RESPONSES }; extern void gcc_jit_context_set_validation (gcc_jit_context *ctxt, gcc_jit_validation_check check, gcc_jit_validation_response response); I'm not in love with any of the above names ("IGNORE" is really "don't bother running this", it's not really a "response"). I wonder if there are any other existing gcc warnings that might be useful to libgccjit users. Thoughts? Dave