From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5347 invoked by alias); 17 Nov 2012 01:05:41 -0000 Received: (qmail 5334 invoked by uid 22791); 17 Nov 2012 01:05:40 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,TW_TM X-Spam-Check-By: sourceware.org Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Nov 2012 01:05:34 +0000 Received: by mail-la0-f47.google.com with SMTP id u2so2598418lag.20 for ; Fri, 16 Nov 2012 17:05:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pTYuZSw4au38Sx8xNkcQQaIhy3/ksBaEtNUsweva8iA=; b=JS7KtpSmuTt2wf68+i2b1E+rnxuB7IovvtyjM68+KHwvztDiRIMUwABT4teJuxtcdu 0Jabo4K7u8hE2oX7UZytx8qEhhK/Foh/4KI2XPlloue6Y87qhfBXxher1oMHopUI99Cx TV9+ZOqDdgMJgBDsQRb9FaoiHv7bsTHPlgOjtDCkd0xD+rFSPwW5Q3n6ZUEByeMVwgH4 VF7po+lph4xfhN7NDh+9Y2j93OG2GSD3r8g8W9uDz+mypjeY6pCcsL/khuJndQMIXm1n /H8Q5/KnM10p6w7ZyZXPleJ7CJ0DKnQpav4CD0ps/D/FSOW2qLpxl4ygV5U9cucr8XVK sgKQ== MIME-Version: 1.0 Received: by 10.152.106.237 with SMTP id gx13mr5686304lab.46.1353114333430; Fri, 16 Nov 2012 17:05:33 -0800 (PST) Received: by 10.152.19.98 with HTTP; Fri, 16 Nov 2012 17:05:33 -0800 (PST) In-Reply-To: References: Date: Sat, 17 Nov 2012 01:05:00 -0000 Message-ID: Subject: Re: Simplifying Gimple Generation From: Xinliang David Li To: Diego Novillo Cc: Lawrence Crowl , "gcc@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlKptJVoT2K8vW/UgIpYbMNK29SPWZP+LouqlN7MJkXoiAHt6otsyRQ7SJ35kcUvqikvzhSajsv/Y1DMElenIxK8lGmApaL9ZepIY8sVHOSUidaoCdjSOU/3XWUFmE28//5drxebC/tFG7ik7ual4uZ8umWiL3BzDXncIBOqj2GEnvkkQbIAZokPwZRxPhpmND9xMYG X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00264.txt.bz2 On Fri, Nov 16, 2012 at 5:13 AM, Diego Novillo wrote: > On Thu, Nov 15, 2012 at 2:31 AM, Xinliang David Li wrote: > >>> ssa_stmt t = q.stmt (NE_EXPR, shadow, 0); >>> ssa_stmt a = q.stmt (BIT_AND_EXPR, base_addr, 7); >>> ssa_stmt b = q.stmt (shadow_type, a); >>> ssa_stmt c = q.stmt (PLUS_EXPR, b, offset); >>> ssa_stmt d = q.stmt (GE_EXPR, c, shadow); >>> ssa_stmt e = q.stmt (BIT_AND_EXPR, t, d); >> >> >> seq_seq::stmt(...) sounds like a getter interface, not a creator. > > Sure. They could be named new_stmt() or build_stmt() or something similar. > >> x = q.new_assignment (...); >> x = q.new_call (..); >> x.add_arg(..); >> x = q.new_icall (..); >> >> l1 = q.new_label ("xx"); >> l2 = q.new_label ("xxx"); >> join_l = q.new_label ("..."); >> >> x = new_if_then_else (cond, l1, l2, join_l); >> q.insert_label (l1); >> q.new_assignment (...); >> q.insert_label(l2); >> ... >> q.insert_label(join_l); >> q.close_if_then_else(x); > > What I was thinking for if_then_else constructs was something along > the lines of: > > stmt_seq then_body(s1); > then_body.add_stmt(s2); > > stmt_seq else_body(r1); > else_body.add_stmt(r2); > stmt if_then_else(cond, then_body, else_body); That looks good. The interface should also allow user to specify branch prob. It is probably useful to consider support creating if-then-else with multiple conditions with short circuit semantics. The interface should look very similar. thanks, David > > You can then take 'if_then_else' and insert it inside a basic block or > an edge. When that happens, the builder takes care of the block/edge > splitting for you. > >>> .. The statement result type is that of the arguments. >>> >>> .. The type of integral constant arguments is that of the other >>> argument. (Which implies that only one argument can be constant.) >>> >>> .. The 'stmt' method handles linking the statement into the sequence. >>> >>> .. The 'set_location' method iterates over all statements. >>> >>> There will be another class of builders for generating GIMPLE >>> in normal form (gimple_stmt). We expect that this will mostly >>> affect all transformations that need to generate new expressions >>> and statements, like instrumentation passes. >> >> What are the uses of the raw forms? > > Sorry, what are these "raw forms" that you refer to? > >>> tree inttype = build_nonstandard_integer_type (POINTER_SIZE, 1); >>> record_builder rec ("__asan_global"); >>> rec.field ("__beg", const_ptr_type_node); >>> rec.field ("__size", inttype); >>> rec.field ("__size_with_redzone", inttype); >>> rec.field ("__name", const_ptr_type_node); >>> rec.field ("__has_dynamic_init", inttype); >>> rec.finish (); >>> tree ret = rec.as_tree (); >> >> Again, something like new_field or add_field is more intuitive. > > Sure. > > > Diego.