From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jit-return-37-listarch-jit=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 27538 invoked by alias); 24 Oct 2013 10:36:51 -0000
Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:jit@gcc.gnu.org>
List-Help: <mailto:jit-help@gcc.gnu.org>
List-Subscribe: <mailto:jit-subscribe@gcc.gnu.org>
Sender: jit-owner@gcc.gnu.org
Received: (qmail 27525 invoked by uid 89); 24 Oct 2013 10:36:50 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.98 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,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: mail-vc0-f174.google.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        bh=wgteZPX6z0jec87vNEI3juvJ+HMVdNskNrSC6QjN7I0=;
        b=J5sczyk2pChV/5xT+MlBoiAn6vYy4QgLMWI/mp1P0tO6sL2eYC0aAdyAE5nUXdqZvI
         TYlhybV0dUUwqY3Ug465p08lzdaY55a6mACCe2Ty399++nSsui4O9q8ROhy/UMjSlM3z
         Sv2xne6vBFZpjfECj1eSMEx96+QcoHAx1nRzmvHhywsUFcImYQFxppYdIHEN/BydRRyk
         VECpn/0UaidNGSpYN95yLutdLCpjw8ihgyVVTKalyUcX1W2sWdlPJhIhGvbMAGrpjbYE
         Wd9awTRQFR+kRTgrj7gPEUlXVEQkMgdw37yYJh3B/DK8FFwUAxONfHn0vZSqesYiQoFM
         Plbw==
X-Received: by 10.58.12.39 with SMTP id v7mr74221veb.47.1382611007281; Thu, 24
 Oct 2013 03:36:47 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <CACc9j8ZHuSHUYUj3mZ_T3d1DOaoGcpg-Ja4saePY12mundFO0A@mail.gmail.com>
References: <CACc9j8ZHuSHUYUj3mZ_T3d1DOaoGcpg-Ja4saePY12mundFO0A@mail.gmail.com>
From: Simon Feltman <s.feltman@gmail.com>
Date: Tue, 01 Jan 2013 00:00:00 -0000
Message-ID: <CACc9j8ae+=s08a+Xbw6PEsVH9dPSGN6yntigHoErtJz+94S7tA@mail.gmail.com>
Subject: Re: Python API (was Re: Build errors)
To: jit <jit@gcc.gnu.org>
Content-Type: text/plain; charset=ISO-8859-1
X-SW-Source: 2013-q4/txt/msg00036.txt.bz2

On Wed, Oct 23, 2013 at 10:20 PM, Simon Feltman <s.feltman@gmail.com> wrote:
> ... This is well beyond my knowledge of compiler architecture,
> but it seems like this could be cleaner?
>
>     the_type = ctxt.get_type(gccjit.Type.INT)
>     local_i = fn.new_local(the_type, b"i")
>
> could be:
>     local_i = fn.new_local(gccjit.Type.INT, b"i")

Digging into this a bit more, it looks like the gccjit API is sort of
synthesizing the context dependence for types anyhow. e.g. gcc
internals already seem to be defining the type nodes as globals
(uint64_type_node). So perhaps the API is attempting to present a new
model which the implementation may morph into?