Thanks Robin and Jeff. > Wouldn't a uint64_t type for max be clearer?
I see, will commit with that change if no surprise from test. > Do we even support this? If so it's surely not well tested :) To double confirm, you mean DImode pattern for rv32? The ANYI iterator restrict the DI to be TARGET_64BIT. If no, I think it is not tested up to a point. > What you do want to watch out for is constants Here I want the max value of unsigned scalar based on mode, it could be UINT8_MAX, UINT16_MAX, UINT32_MAX and UINT64_MAX. Pan -----Original Message----- From: Jeff Law <jeffreya...@gmail.com> Sent: Saturday, July 5, 2025 9:46 AM To: Robin Dapp <rdapp....@gmail.com>; Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Chen, Ken <ken.c...@intel.com>; Liu, Hongtao <hongtao....@intel.com> Subject: Re: [PATCH v3 3/4] RISC-V: Implement unsigned scalar SAT_MUL from uint128_t On 7/4/25 1:18 PM, Robin Dapp wrote: > This generally looks OK to me (including the tests). > >> + HOST_WIDE_INT max = ((uint64_t)1 << bitsize) - 1; > > Wouldn't a uint64_t type for max be clearer? I guess the worst that can > happen is compiling on a 32-bit host for a 64-bit target and get bitsize > == 32 here. > Do we even support this? If so it's surely not well tested :) It's definitely not well tested, I just integrated a patch from Andrew P. which fixed a problem in this space in the port. But I strongly suspect more issues are lurking. Note that HOST_WIDE_INT is a minimum of 64 bits these days, even if it has to be implemented as a long long under the hood. What you do want to watch out for is constants. HOST_WIDE_INT_C HOST_WIDE_INT_UC can be used to generate constants that are safe in both a 32 and 64 bit host world. Jeff
