From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 302253857831 for ; Wed, 10 Jan 2024 14:47:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 302253857831 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 302253857831 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704898059; cv=none; b=l45+CnaNwrE2Ff8fSG/OzYaOe2DpaMgFCstLR6zLqVhGOUtJbHmILo/FUNh2F4Pj8YQIosqRasm7dDxJxk7L4Bi3aD9UKMyh353SKEiVrq7u2120vqpTNKUZ1Z4DFZ6FwcgxXYJHYeqX6S4kP4x9P7P8fuibh+QalFafZd8m4jg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704898059; c=relaxed/simple; bh=Ms2Tt2UOSPzVmeQxibn0I0KNkkADSU0U6psNPr9jze4=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=QLx/yntsSfdwL/HDymsRrcncN/2SrSSqj0uFUVgsTwJ76IwJTiMAOxJdTEAFIFLWT1oZ23cM/6lRShyW2hmxxhL7QsmhwqL+OrOPhzVjkOMlRH0kse0KMtP7jvoDCf2gyzgTgnp1POCm1o00gSSh/3arGD0M5XBLS8JSgY4kFDE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704898057; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6ruAeoQdfyFVizf1oE4rGQ5WRrynk6UIVe+i8B/sykQ=; b=hxDF0fs0eSGLgiX8yrcZTk1jJS3E+gr2XqHYU6h3gMteDE0Ni+mLFDkg/tXEJSX7tDlszE vnCgvydCblJfZj7nw6r8kD2b8ECfpdCLIWY9mumxrmhrxrk6kRCG6ndjb35RmK6CD4ByoI jtzk+LCtW85klq52YkcNiIRZMaE8QHY= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-383-WNQO_QDVPN-YHbr-YnfY8w-1; Wed, 10 Jan 2024 09:47:36 -0500 X-MC-Unique: WNQO_QDVPN-YHbr-YnfY8w-1 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-68104661bbdso55904476d6.3 for ; Wed, 10 Jan 2024 06:47:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704898055; x=1705502855; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6ruAeoQdfyFVizf1oE4rGQ5WRrynk6UIVe+i8B/sykQ=; b=ALe3x5BXPkdyq4i1iiRw5fH0lhO/ATL+K6worJt0MvkHBuXsaYl8R7KiPcN6ExMxwj fqP+NbF+/CW/Hda0zL13mIToPxoYfXmjcBVhrTIFdqDPe1KauBjMc62HuKDvuB4FY8sk q4xk49MCJNUswkRbOnf2naRf1Fni6vk6fz5dVsztml5dJPvlidVMqmKpJinYAJ4UE1cp 0270L9tgm0i9fNYO5swEXQS13JsQcVZUaCrr0tf+JO+jTmgDk7WL9NMQbPl5gjAtb7Kp te6bt0zbyzNkNZzjqKSllNbWzyOrULa+Y9FvcKVCdoR5kewyZSaPTMr1tvzHvAOaTd5k Zr2Q== X-Gm-Message-State: AOJu0YyNKe1fTTluKXv0GvALYWIWaYN5PTO1aBsXnFEkInTBS4NsHUoQ eIPW4PWc5afl+cRn0BAH+n+0XoD+hPsHO65XcwBpT8fWpipqYUzAlOS4655YJmZsdG8H8MTU7SJ AU7NHySf0HQkNL+U= X-Received: by 2002:a05:6214:27c8:b0:681:a12:2afc with SMTP id ge8-20020a05621427c800b006810a122afcmr1370020qvb.61.1704898055752; Wed, 10 Jan 2024 06:47:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IHKaKKmJOdN7+CuY1eBbd+Wq/xCNp3ogcheFo+4yrbWEtWFS1/RcAZarUJCSgEKn0FbhWQdxA== X-Received: by 2002:a05:6214:27c8:b0:681:a12:2afc with SMTP id ge8-20020a05621427c800b006810a122afcmr1370009qvb.61.1704898055403; Wed, 10 Jan 2024 06:47:35 -0800 (PST) Received: from t14s.localdomain (c-76-28-97-5.hsd1.ma.comcast.net. [76.28.97.5]) by smtp.gmail.com with ESMTPSA id w20-20020a0562140b3400b0067ccfe57750sm1728528qvj.145.2024.01.10.06.47.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 06:47:34 -0800 (PST) Message-ID: Subject: Re: [PATCH] libgccjit Fix a RTL bug for libgccjit From: David Malcolm To: Jeff Law , Antoni Boucher , jit@gcc.gnu.org, gcc-patches@gcc.gnu.org Date: Wed, 10 Jan 2024 09:47:34 -0500 In-Reply-To: References: <7c598b42-f866-4661-8682-818e7e7bbccf@gmail.com> <5552026bb6829cc0df67b11576ed1d02efd8eaee.camel@zoho.com> <7d819703-37fe-414c-b65d-e7a4c3fc9d17@gmail.com> <80b6dae50b4011b6a6a6b36da8555937fa0f4de7.camel@redhat.com> <0c86682b-9e80-4d15-9692-d011129d1cbe@gmail.com> User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 2023-12-11 at 09:06 -0700, Jeff Law wrote: >=20 >=20 > On 11/20/23 16:54, David Malcolm wrote: > > On Mon, 2023-11-20 at 16:38 -0700, Jeff Law wrote: > > >=20 > > >=20 > > > On 11/20/23 15:46, David Malcolm wrote: > > > > On Fri, 2023-11-17 at 14:09 -0700, Jeff Law wrote: > > > > >=20 > > > > >=20 > > > > > On 11/17/23 14:08, Antoni Boucher wrote: > > > > > > In contrast with the other frontends, libgccjit can be > > > > > > executed > > > > > > multiple times in a row in the same process. > > > > > Yup.=C2=A0 I'm aware of that.=C2=A0 Even so calling init_emit_onc= e more > > > > > than > > > > > one > > > > > time still seems wrong. > > > >=20 > > > > There are two approaches we follow when dealing with state > > > > stored > > > > in > > > > global variables: > > > > (a) clean it all up via the various functions called from > > > > toplev::finalize > > > > (b) make it effectively constant once initialized, with > > > > idempotent > > > > initialization > > > >=20 > > > > The multiple in-process executions of libgccjit could pass in > > > > different > > > > code-generation options.=C2=A0 Does the RTL-initialization logic > > > > depend > > > > anywhere on flags passed in, because if so, we're probably > > > > going to > > > > need to re-run the initialization. > > > The INIT_EXPANDERS code would be the most concerning as it's > > > implementation is totally hidden and provided by the target. I > > > wouldn't > > > be at all surprised if one or more do something evil in there.=C2=A0 > > > That > > > probably needs to be evaluated on a target by target basis. > > >=20 > > > The rest really do look like single init, even in a JIT > > > environment > > > kinds of things -- ie all the shared constants in RTL. > >=20 > > I think Antoni's patch can we described as implementing "single > > init", > > in that it ensures that at least part of init_emit_once is single > > init. > >=20 > > Is the posted patch OK by you, or do we need to rework things, and > > if > > the latter, what would be the goal? > What I'm struggling with is perhaps a problem of naming.=C2=A0 > Conceptually=20 > "init_emit_once" in my mind should be called once and only once.=C2=A0=C2= =A0=C2=A0 > If I=20 > read Antoni's change correctly, we call it more than once. I'm afraid we're already doing that, Antoni's proposed patch doesn't change that. In toplev::finalize we try to clean up as much global state as possible to allow toplev::main to be runnable again. From that point of view "once" could mean "once within an invocation of toplev::main" (if that makes it feel any less gross). > =C2=A0 That just > feels conceptually wrong -- add to it the opaqueness of > INIT_EXPANDERS=20 > and it feels even more wrong -- we don't know what's going on behind > the=20 > scenes in there. Given these various concerns, I think we should go with approach (a) from above: add an emit_rtl_cc::finalizer function, and have it reset all of the globals in emit-rtl.cc. That seems like the most clear way to handle this awkward situation. Dave