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.133.124]) by sourceware.org (Postfix) with ESMTPS id A88753858CDB for ; Fri, 8 Dec 2023 17:49:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A88753858CDB 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 A88753858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702057802; cv=none; b=jaHtkiJos86gLkhxuYRPSxhow2KebAk780tFjdWKCb3Efl/WOTKl0CfvkuNCPkncJ1svieWdbMxoSbLHjnVR0DpyrPg5Qbe2TIiiQfHgGlLxBn8E5uob2/+VaRsveg/AjaV7tfoiQhQblnJku40I80wiKWF/zDgVoDBGfHMXFZc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702057802; c=relaxed/simple; bh=g66OX0E8Ww5g2BSNDhAf5Fw/NSIZNI9aXOmvtKKhOBg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ihaHflA64fmsXYDtHcjLxlTWITMzfYCm2dt0zeKGlJaEmHkkUbmbRasexDVklJabP2sOFAjitXY8aGED1MM6Cxm99DZsKGvGVKzNY+OVBvfaEXPK0J+QuRjMVuJbIvEnN0Z/lyV/4Xmgg4AksGeAkR95IJmEICS+d14kwuijiMw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702057791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DZMZ/Z6wcABK8ZuRXEo94I1KrXFesi7bXdDLAAEREAc=; b=ejTupr/5WzTYaBLhN3CVMdQhfvWVlBG0gLKVThWufzeNFlF/kZTYXpaR6Gi2n2KHmYo438 2OHkaaMl2pL/gYiPsceEfCRhq2Gr+xFjl/To/uMLfxMHgFtpaCUBo39oeDPufMAf0AqSUl GrkSgd7QmbbSTKjaWLHdoV27h0itnn4= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-182-sAhaZfS0OG-tG-m8j0ZrIA-1; Fri, 08 Dec 2023 12:49:49 -0500 X-MC-Unique: sAhaZfS0OG-tG-m8j0ZrIA-1 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-423d293392bso25542171cf.2 for ; Fri, 08 Dec 2023 09:49:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702057789; x=1702662589; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DZMZ/Z6wcABK8ZuRXEo94I1KrXFesi7bXdDLAAEREAc=; b=mE9hRS84QPtxOg0pndx9EXXPYclG6oqoO55ZuIv3D1qnoXDY9nw6+kozRkDqIqRSXw zE3BqGKfGuR8NibB0MOm8YIDmqoyRnaNTVzthhNsDC46hEuMBI8iqVYQUSrADAjj5FpY 2dASijoValUZpCcYP1jr6RheHYSzb6Vg1fTqzmsxW/vEmCdM1au9MqtNUhagCdI4Pg4n wgfahqqWGYSO6OH2zyBgnTdxrCjP5+ZM3dL3X57OxZ+1NXqt+LmnbCXnI4vPHsBI1T8X dSo4uZ7oxowdVpEDhX/JSSUt4fvFM8W4GJVzJ/L9Xf728nHngwF1qLCkvftov23MDH9Z Lvaw== X-Gm-Message-State: AOJu0YwnwlAumDz0oG8o1ww0ki6RYceYzwNX54HE8L/ZiGAPEIzcH1iG zU54MmYcakeVJxf7dPcIRPpEl9DgEwbUypgHfqiDt59z93LFj1gsur9tITtayoCVbpR11v6T/K/ xTrHiBdex4Kn3msH5Xg== X-Received: by 2002:ac8:5c0c:0:b0:423:e2f5:d16 with SMTP id i12-20020ac85c0c000000b00423e2f50d16mr570653qti.3.1702057789435; Fri, 08 Dec 2023 09:49:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IEdi6XfITUOepe9G4n55Q/1XPPknWfb9dGdUtIHzjHcQbJYopEWBKdxHrvphkX6kjybDoaSWw== X-Received: by 2002:ac8:5c0c:0:b0:423:e2f5:d16 with SMTP id i12-20020ac85c0c000000b00423e2f50d16mr570640qti.3.1702057789170; Fri, 08 Dec 2023 09:49:49 -0800 (PST) Received: from [192.168.1.88] (23-233-12-249.cpe.pppoe.ca. [23.233.12.249]) by smtp.gmail.com with ESMTPSA id j10-20020ac8550a000000b00424059fe96esm962003qtq.89.2023.12.08.09.49.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Dec 2023 09:49:48 -0800 (PST) Message-ID: <03ab3f28-2a84-2e13-93b0-3c8681fcf7da@redhat.com> Date: Fri, 8 Dec 2023 12:49:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] v2: Add IntegerRange for -param=min-nondebug-insn-uid= and fix vector growing in LRA and vec [PR112411] To: Jakub Jelinek , Richard Biener Cc: gcc-patches@gcc.gnu.org References: From: Vladimir Makarov In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK 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 12/7/23 03:39, Jakub Jelinek wrote: > On Thu, Dec 07, 2023 at 09:36:22AM +0100, Jakub Jelinek wrote: >> So, one way to fix the LRA issue would be just to use >> lra_insn_recog_data_len = index * 3U / 2; >> if (lra_insn_recog_data_len <= index) >> lra_insn_recog_data_len = index + 1; >> basically do what vec.cc does. I thought we can do better for >> both vec.cc and LRA on 64-bit hosts even without growing the allocated >> counters, but now that I look at it again, perhaps we can't. >> The above overflows already with original alloc or lra_insn_recog_data_len >> 0x55555556, where 0x5555555 * 3U / 2 is still 0x7fffffff >> and so representable in the 32-bit, but 0x55555556 * 3U / 2 is >> 1. I thought (and the patch implements it) that we could use >> alloc * (size_t) 3 / 2 so that on 64-bit hosts it wouldn't overflow >> that quickly, but 0x55555556 * (size_t) 3 / 2 there is 0x80000001 >> which is still ok in unsigned, but given that vec.h then stores the >> counter into unsigned m_alloc:31; bit-field, it is too much. >> >> The patch below is what I've actually bootstrapped/regtested on >> x86_64-linux and i686-linux, but given the above I think I should drop >> the vec.cc hunk and change (size_t) 3 in the LRA hunk to 3U. > Here is so far untested adjusted patch, which does the computation > just in unsigned int rather than size_t, because doing it in size_t > wouldn't improve things. > > 2023-12-07 Jakub Jelinek > > PR middle-end/112411 > * params.opt (-param=min-nondebug-insn-uid=): Add > IntegerRange(0, 1073741824). > * lra.cc (check_and_expand_insn_recog_data): Use 3U rather than 3 > in * 3 / 2 computation and if the result is smaller or equal to > index, use index + 1. > > * gcc.dg/params/blocksort-part.c: Add dg-skip-if for > --param min-nondebug-insn-uid=1073741824. > Jakub, if you are still waiting for an approval,  LRA change is ok for me with given max param. Thank you for fixing this.