From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) by sourceware.org (Postfix) with ESMTPS id 397993864877 for ; Fri, 30 Jun 2023 12:45:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 397993864877 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-1b03ec2015fso1583621fac.3 for ; Fri, 30 Jun 2023 05:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1688129150; x=1690721150; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yLXpR/i+dHOlq1hJPlUdf3/50MpCAYbVQjGfqO274lA=; b=HD0tsuw+EtFm+InJQL4Zuhq50uCgraxPT+lP3kxFJe1Dp5ilslp5c8+CVureqde0OO rVKOFpZVaA/4ros1qTiWe6FF5cePZNkFoqsluG3gjoui/sfIMXwdY+IFhxzOoXd28IzA IoKLYj6NJlJ7YHa2ScmYTATJFz5b8LGv1p+XX0z9tJFfb3qhZrRt2f1bRawxEoUwtnT2 v98HgdwxRgWPdHEvu1vYXX3EzmX2g/hvCJ4K5Ez+nPvFYQCX1MV8a674hrnwQ4fMUOia iIa9zWpe8o3cOm3ekuCtuhCaLmcXmiJDIKw6cQH2+5LLZsWnWoqeolDdxxmOQfYgDVPV zCvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688129150; x=1690721150; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yLXpR/i+dHOlq1hJPlUdf3/50MpCAYbVQjGfqO274lA=; b=aaopBdnG7F2SP27+YiFet7NY/qgtI0sQn8DtJELkbgZjOZ4hzEzUiKemO/paw9oE6x HOLnfEai7HlsnzCaj9xF88t6YMS/NRAFw5rDSkLlDumC+XEen9O4YuC3m3YTUnK4ULWY s7bVlh1jAcW3UXpU38Lv2kSJlwF19wROIH6VFtkZKSxgEOhQdEIoshVcfhsOHI0S9PAs 4OoBBWPTijIvSBbB6XwPXnL2D3qufwDF9hESey/7bcHyHddUDLfbTRm/PM04dN5uaLIi SKCMgGe2Vz3crhGm/JomuHAOuq64IDZUYBst+M84pAf6Ikrl4mcCvfnfdj/WNBnCB28R SQUQ== X-Gm-Message-State: ABy/qLaO+JIHUtOyvRfUwOnjJ1dW+WE8x8ibMQrp0QY1X44cLX54uNv1 rE5inMhGj2DR66eKXRTyg8HeW+ZfTqW2WrWoNqfOHg== X-Google-Smtp-Source: APBJJlEbWnnLoYpIUC6j6AIIUN06949yH0HeJHNMBWqze6655lFM5zgnEnA6mAQOvYpjrJi4gZO4PTvy1yu6Y7JN4kU= X-Received: by 2002:a05:6871:548:b0:1b0:5f67:283c with SMTP id t8-20020a056871054800b001b05f67283cmr3576401oal.15.1688129150358; Fri, 30 Jun 2023 05:45:50 -0700 (PDT) MIME-Version: 1.0 References: <20230512050016.476110-1-pan2.li@intel.com> <2CEAD79B-D664-41B4-A337-5E77ECFB2F9D@gmail.com> <87o7kxuq9s.fsf@euler.schwinge.homeip.net> In-Reply-To: <87o7kxuq9s.fsf@euler.schwinge.homeip.net> From: Kito Cheng Date: Fri, 30 Jun 2023 20:45:38 +0800 Message-ID: Subject: Re: Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits" (was: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits) To: Thomas Schwinge Cc: Richard Biener , gcc-patches@gcc.gnu.org, pan2.li@intel.com, Bernhard Reutner-Fischer , Jakub Jelinek , juzhe.zhong@rivai.ai, yanzhang.wang@intel.com, jeffreyalaw@gmail.com, richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches wrote: > > Tried this patch and I ran into some issues, some variables are using > > unsigned char to hold machine mode and will have problems when the > > number of modes is larger than 255... > > > > And here is the fix: > > > --- a/gcc/genmodes.cc > > +++ b/gcc/genmodes.cc > > @@ -1141,10 +1141,10 @@ inline __attribute__((__always_inline__))\n\ > > #else\n\ > > extern __inline__ __attribute__((__always_inline__, __gnu_inline__))\n\ > > #endif\n\ > > -unsigned char\n\ > > +unsigned short\n\ > > mode_inner_inline (machine_mode mode)\n\ > > {\n\ > > - extern const unsigned char mode_inner[NUM_MACHINE_MODES];\n\ > > + extern const unsigned short mode_inner[NUM_MACHINE_MODES];\n\ > > gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\ > > switch (mode)\n\ > > {"); > > @@ -1529,7 +1529,7 @@ emit_mode_wider (void) > > int c; > > struct mode_data *m; > > > > - print_decl ("unsigned char", "mode_next", "NUM_MACHINE_MODES"); > > + print_decl ("unsigned short", "mode_next", "NUM_MACHINE_MODES"); > > Etc. > > Instead of 's%char%short', shouldn't we really be using > 'enum machine_mode' here? (I understand such a change may require some > further surgery, but wouldn't it be the correct thing to do?) Hmmm, I think maybe what we need is to leverage C++ language features to declare enum with underlying types like that: enum machine_mode : uint16_t