From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 363903857C52 for ; Mon, 16 Nov 2020 18:20:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 363903857C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hainque@adacore.com Received: by mail-wm1-x334.google.com with SMTP id c9so213108wml.5 for ; Mon, 16 Nov 2020 10:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NRo0PNcs03E3zHgE2fS1s14CCWY1LIkVCrl9LqxoLGU=; b=mMUsAZi8q/lpNeP4zQVNG5PPfCGLktZL4BE+R01A4kS9mrn1sTjzJk3Wa9TAV3rkcI LhbVD84iFLN7DXEWycyWfB2Sdka+D8AmLwDQREGK2BaNcXBViAMu3u9viBDupjpSOwUq Zo/dJ4uvrjiF1vXaCi9FxxKOsuzAerq2pQhl/sZ2fU/SZ8c3JpW0snBWSnfISpc4PCqC +jgXuIqNRd+S2wiYMVR262R+CAOwgGH9uC8K9He3ZNjjLumObL0Qi/bv5qrRuv7kF/gt /w3jNkgt9OZIN0k++rD7a2nbG6iYb7oPbVz5eeoj9tRclgfFoqdjoxMFLmFD1SlRYW/t sPhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NRo0PNcs03E3zHgE2fS1s14CCWY1LIkVCrl9LqxoLGU=; b=T4GfZrqhINj67bs+3cHDCZaUJJdVAwkgChvXrWsBETAFklYFkIuFdIgAO264USgToA Hiw/R0/dTUhakQhobiNqvr5cgLZSv3nS7ILEBsPH8tr9rnlpEPc1xmLQ2jTjz+xkx8ew T9KvVGNu9beCkJalDz6XiGiDMD7yks9XXp3SE358/bgIe0Eby9X9P+ju3HJ+YaPhJ2UO OhIZ5BmfZPg7EPRqN1z1MpQFxYK0R3sj73zrnAn5u57DGRK4smllbx++onYenRat6c7s dAQiCsPP7D8GtX/eBT0/6D9UqO7KHZls8WM3C2hQNOwQyNyMUXPO5YCz59pXTp40XNu6 s9Yg== X-Gm-Message-State: AOAM533GrEijRU4PnttDuOD6AGAVoNy5+cQO7i5yy4PmugQ3WBuL+CEa ZX3+dg17ciWa13EIo0u/YUdbOA== X-Google-Smtp-Source: ABdhPJy8OFQmTyAO8R0rDU43HK4tnI+sQM2hXHXia1JihgdyViIfIkj5Ql0bElQ1C5JXUj4hVQbXfA== X-Received: by 2002:a1c:4e0e:: with SMTP id g14mr171886wmh.9.1605550808175; Mon, 16 Nov 2020 10:20:08 -0800 (PST) Received: from imac-2020.home (2a01cb0002912700851a4aa0cc8da26e.ipv6.abo.wanadoo.fr. [2a01:cb00:291:2700:851a:4aa0:cc8d:a26e]) by smtp.gmail.com with ESMTPSA id r8sm23661708wrq.14.2020.11.16.10.20.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 10:20:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: introduce overridable clear_cache emitter From: Olivier Hainque In-Reply-To: Date: Mon, 16 Nov 2020 19:20:07 +0100 Cc: Olivier Hainque , gcc-patches@gcc.gnu.org Content-Transfer-Encoding: 7bit Message-Id: <003E334A-B4DE-4F2C-BBA3-3B39D91A5EA1@adacore.com> References: To: Alexandre Oliva X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 18:20:10 -0000 Hi Alex, Thanks for your proposal on this! > On 11 Nov 2020, at 03:35, Alexandre Oliva wrote: > > This patch introduces maybe_emit_call_builtin___clear_cache for the > builtin expander machinery and the trampoline initializers to use to > clear the instruction cache, removing a source of inconsistencies and > subtle errors in low-level machinery. > > I've adjusted all trampoline_init implementations that used to issue > explicit calls to __clear_cache or similar to use this new primitive. > > Specifically on vxworks targets, we needed to drop the __clear_cache > symbol in libgcc, for reasons related with linking that I didn't need > to understand, and we wanted to call cacheTextUpdate directly, despite > the different calling conventions: the second argument is a length > rather than the end address. The initial VxWorks issue is essentially that recent (llvm based) environments know __clear_cache as a builtin and refuse to statically link modules that contain an exposed symbol with that name. As VxWorks (indeed) has a public API for the kind of insn cache clearing operations we need, it just seems natural to arrange to call it directly instead of going through an intermediate wrapper in libgcc. This is a bit more efficient and removes a dependency on libgcc, a good thing in an environment where there are multiple ways to link things together. It also seems like a positive thing to tighten the connection/consistency between what trampolines and __builtin_clear_cache do, as they're supposed to be used for similar purposes AFAICT. > So I introduced a target hook to enable target OS-level overriding of > builtin __clear_cache call emission, retaining nearly (*) the same > logic to govern the decision on whether to emit a call (or nothing, or > a machine-dependent insn) but enabling a call to a target > system-defined function with different calling conventions to be > issued, without having to modify .md files of the various > architectures supported by the target system to introduce or modify > clear_cache insns. No strong feeling on the means here, so I'll defer to other maintainers on the approach. IIUC, the patch intends not to change the behavior of back-ends on the trampoline init paths, which seems like a key property to me. Olivier