From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id 4EECD3857367 for ; Fri, 28 Oct 2022 00:44:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4EECD3857367 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pj1-x1033.google.com with SMTP id d13-20020a17090a3b0d00b00213519dfe4aso3131324pjc.2 for ; Thu, 27 Oct 2022 17:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=message-id:to:from:cc:in-reply-to:subject:date:from:to:cc:subject :date:message-id:reply-to; bh=KEg6nc5wXYLR7LGEkqTzWyU6sS+VpITy/fOQfA/KaRg=; b=wGVoJtQkSFHMMU2d9sIuCRzjacdWijAp0A/tOhKTMn70qTF82O5P3KH/FsxOSuS89P kzYQODetOznAVIpfBQViny7ffXKgTfvjvCx+/WKT1pjccKJAyiNXv+frge0/YgzZHe1W Kpi9oq2FWdZDjD+GSdv0vg1E+doGU+xIlqGzlhcf4B3BuZ9hplVLE6Ry62tzF2ul+h4z qdNOOpi4K+m3V8bE9JJcOySCxySqQWvm1Tu7tDUvmmsFGp24mWN2LJV63jrbF/YZQkOL sxzjIahMPRSyUUAb5wtnUKBbRnCo3BIvcKQ3zORN/mDFkCjGUKDdb0Q9+P4wZsLmLpg9 xQeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:to:from:cc:in-reply-to:subject:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KEg6nc5wXYLR7LGEkqTzWyU6sS+VpITy/fOQfA/KaRg=; b=ORJ16zrYC/xtA/8DV+bm4Ck+W6+2wy4loZ6tao20Pe6HUWsRF7SPzC0rcXJJ3aek+a 7QBdJKBpcTt/bt/tcUNy6p3M7ROFZaUj97ORnslvB6+AT59vwYwxDrQn3SitDxL1cR0k EdrOULPLf0CBLz7D/DSYKWdhKC6nEvmKkI1v/3OAvrNxYxGkP1c7ipRW4dRsuqr1hgLM VcuEkWGHntCIz34TQ9psmDKpxyjKyzALQchHjIL0hmfMzAGfwiBqXLem6UVpbMjX8tyH VfIkhxoM5KXRKLYVgCbUITlCxbvckrezP1CMYDQvDOjrAZboM6MCr37nmAHKckO4iUrV ZOCQ== X-Gm-Message-State: ACrzQf273a86zaMu38mGWAQ0t/hHWDh6qTdDfwOP9EysJlgQGtZ+J6/O MGmv15X7EcPM+s2Nh/leWxWwrQ== X-Google-Smtp-Source: AMsMyM6U2KdnmyEGI/4XUOJXBHkiVc5Olg+V376/2lHz7LF85EByBQRpLzn37TKObCc46pYQxi3+Sw== X-Received: by 2002:a17:90a:cb8b:b0:211:7744:d155 with SMTP id a11-20020a17090acb8b00b002117744d155mr12897797pju.187.1666917896279; Thu, 27 Oct 2022 17:44:56 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id t2-20020a170902e84200b00176dc67df44sm1804026plg.132.2022.10.27.17.44.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Oct 2022 17:44:55 -0700 (PDT) Date: Thu, 27 Oct 2022 17:44:55 -0700 (PDT) X-Google-Original-Date: Thu, 27 Oct 2022 16:54:15 PDT (-0700) Subject: Re: [PATCH v2] RISC-V: Libitm add RISC-V support. In-Reply-To: <5ac3d38a-27c1-cc4a-dc4b-9d82e109503a@gmail.com> CC: xc-tan@outlook.com, gcc-patches@gcc.gnu.org, fantasquex@gmail.com, Andrew Waterman From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org Message-ID: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,PP_MIME_FAKE_ASCII_TEXT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Thu, 27 Oct 2022 16:05:19 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > > On 10/27/22 06:49, Xiongchuan Tan via Gcc-patches wrote: >> libitm/ChangeLog: >> >> * configure.tgt: Add riscv support. >> * config/riscv/asm.h: New file. >> * config/riscv/sjlj.S: New file. >> * config/riscv/target.h: New file. >> --- >> v2: Change HW_CACHELINE_SIZE to 64 (in accordance with the RVA profiles, see >> https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) >> >> libitm/config/riscv/asm.h | 52 +++++++++++++ >> libitm/config/riscv/sjlj.S | 144 +++++++++++++++++++++++++++++++++++ >> libitm/config/riscv/target.h | 50 ++++++++++++ >> libitm/configure.tgt | 2 + >> 4 files changed, 248 insertions(+) >> create mode 100644 libitm/config/riscv/asm.h >> create mode 100644 libitm/config/riscv/sjlj.S >> create mode 100644 libitm/config/riscv/target.h > > Not objecting or even reviewing....  But hasn't transactional memory > largely fallen out of favor these days?  Intel has pulled it and I think > IBM did as well.    Should we be investing in extending libitm at all? I think we didn't get the memo: https://github.com/riscv/riscv-isa-manual/pull/906 The code looks fine to me, so Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt though I don't have an opinion on whether libitm should be taking ports to new targets, I'd never even heard of it before. Some minor comments: > +_ITM_beginTransaction: > + cfi_startproc > + mv a1, sp > + addi sp, sp, -(14*SZ_GPR+12*SZ_FPR) > + cfi_adjust_cfa_offset(14*SZ_GPR+12*SZ_FPR) Many of the ABIs require 16-byte stack alignment. Also: it doesn't hurt anything to use the extra stack, but we only stricly need space for the FPRs if we're going to bother saving them. > +/* ??? The size of one line in hardware caches (in bytes). */ > +#define HW_CACHELINE_SIZE 64 Maybe we should have a placeholder libc/vdso routine for the cache line size? The specs are sort of just a suggestion for that sort of thing. > +static inline void > +cpu_relax (void) > +{ > + __asm__ volatile ("" : : : "memory"); > +} We have Zihintpause now, but that's a pretty minor optimization.