From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 2C8C73858C5E for ; Mon, 4 Dec 2023 09:15:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C8C73858C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2C8C73858C5E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::32d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701681329; cv=none; b=Wtb56/jcovEGH0gendlps1ER4q2NC/69PLSsV6DkMrIx5nCuGpuL0c0d3JauWG4mqYR98P9ph0P34x90/3gQ94US+UUwDTVBVhn6HWvSCkanizaBZrl6qqvpCu3Tmif7Rw89bv+Gnvz+UYHHdDygT5SAQa5cGjRfQET/ct1lZTg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701681329; c=relaxed/simple; bh=vCSQqJVZWqtgvQaaUWUz3nFhMm9uUteU7yBOuyoem9U=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=lKEjly5lcOve/CFI/GOvfyhKtcuMUhEE+ZuLk1HKgx85oYGxZGU9lEqH4yoHQeMVogO22e56n8gdb5cLLfhEMM6gxtcSV3lHhLQ2nvFqxrziO5J6hTZZsD4496k6/987G8oYjrAqb//HPQJ9bRf/EkZikCyEP8GJ22PRKoBg0Gs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-40b5155e154so43149215e9.3 for ; Mon, 04 Dec 2023 01:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1701681326; x=1702286126; darn=gcc.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=lG38vyRbeI4ZxtMUtx6dxxQh8zcUp9H7irO1Oa5bPlI=; b=m0KBmTj5bRA3xFHpa4tB9dPWw1pgMyWpaRXhXg0x+CW7WtMegPPclcEkpDpfSWE2/Z hUl61IR4sH4mR/OdmSHslDmeQ1VH6qXhc+alq4Ha6tB93QhXso3W6raRP/Vv2FnjA3R8 NwoWLrB1IaUJ7S+QVmJexv3nwsfy/0OOC49gtwIfTIEjNPZV0oWHfHon9pFvIGKcPK52 6U+99xGLIwaDfF4vzMKGhhPpMiLpQhnbPBBVlzLh1V/mLjhHycxmfCikuJZgw6smrFzq DcbCTNdxWShI22hD7vTq7KNazFNLXpB4yqtb/PWk2Xdvf+0pbmzPx80pODGXKx94Xon2 yDFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701681326; x=1702286126; h=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=lG38vyRbeI4ZxtMUtx6dxxQh8zcUp9H7irO1Oa5bPlI=; b=P7FGDalbQPrwMUUD8KaZc673vEgd6bwUeB+x4C9LnfMXFHvLAtdM09pKXjw31tPkwk 5yKevmAi8VWKo5Yh6TUJmUrtvdX65I0EHV5NWYCduCY10Xs9stNm4I+j/9uXfrAiR9Lu 9sZC68cG/vhE6KR/QE9i/T+nLW+9iPSUewUeSC+5h8vXgdVTRDfpfeiVsIz9CiZQ0sLm vvJmLlKtVopI4AQuOCOj5b/7dMtWppIOaNMbBiCIk1z8saqsasxG+FtA3v/L7YCcempG /SKKSXe3T6J2yil+cRNX83fBxVmXQc2AwScjVqZllS5mmcGWDuwTALEPzX5PBK+mZsf9 GyFQ== X-Gm-Message-State: AOJu0YwYkTua69RGM7EoMHRBHhzCLQKYtRXeVN8WhBr2IR8bJano8lY6 bePqaqaXpklroRRJyuspIqJdih1hm07By7TespwKvGEtLaFjYYe6cOg= X-Google-Smtp-Source: AGHT+IGvCYTEnxPPVUnrZLdEW85K9Hr5yVdXJlJILyQhUOmLu0ivbwC2AOsiHJejBOp/+NlxqK3FlhyzbjwGZUAqWJU= X-Received: by 2002:a05:600c:19d2:b0:40b:5004:7e2d with SMTP id u18-20020a05600c19d200b0040b50047e2dmr1937888wmq.26.1701681325750; Mon, 04 Dec 2023 01:15:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Prathamesh Kulkarni Date: Mon, 4 Dec 2023 14:44:49 +0530 Message-ID: Subject: Re: [aarch64] PR111702 - ICE in insert_regs after interleave+zip1 vector initialization patch To: Richard Sandiford , gcc Patches 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,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT 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, 23 Nov 2023 at 17:06, Prathamesh Kulkarni wrote: > > Hi Richard, > For the test-case mentioned in PR111702, compiling with -O2 > -frounding-math -fstack-protector-all results in following ICE during > cse2 pass: > > test.c: In function 'foo': > test.c:119:1: internal compiler error: in insert_regs, at cse.cc:1120 > 119 | } > | ^ > 0xb7ebb0 insert_regs > ../../gcc/gcc/cse.cc:1120 > 0x1f95134 merge_equiv_classes > ../../gcc/gcc/cse.cc:1764 > 0x1f9b9ab cse_insn > ../../gcc/gcc/cse.cc:4793 > 0x1f9fe30 cse_extended_basic_block > ../../gcc/gcc/cse.cc:6577 > 0x1f9fe30 cse_main > ../../gcc/gcc/cse.cc:6722 > 0x1fa0984 rest_of_handle_cse2 > ../../gcc/gcc/cse.cc:7620 > 0x1fa0984 execute > ../../gcc/gcc/cse.cc:7675 > > This happens only with interleave+zip1 vector initialization with > -frounding-math -fstack-protector-all, while it compiles OK without > -fstack-protector-all. Also, it compiles OK with fallback sequence > code-gen (with or without -fstack-protector-all). Unfortunately, I > haven't been able to reduce the test-case further :/ > > From the test-case, it seems only the vector initializer for type J > uses interleave+zip1 approach, while rest of the vector initializers > use fallback sequence. > > J is defined as: > typedef _Float16 __attribute__((__vector_size__ (16))) J; > > and the initializer is: > (J) { 11654, 4801, 5535, 9743, 61680} > > interleave+zip1 sequence for above initializer J: > mode = V8HF > > vals: (parallel:V8HF [ > (reg:HF 642) > (reg:HF 645) > (reg:HF 648) > (reg:HF 651) > (reg:HF 654) > (const_double:HF 0.0 [0x0.0p+0]) repeated x3 > ]) > > target: (reg:V8HF 641) > seq: > (insn 1058 0 1059 (set (reg:V4HF 657) > (const_vector:V4HF [ > (const_double:HF 0.0 [0x0.0p+0]) repeated x4 > ])) "test.c":81:8 -1 > (nil)) > (insn 1059 1058 1060 (set (reg:V4HF 657) > (vec_merge:V4HF (vec_duplicate:V4HF (reg:HF 642)) > (reg:V4HF 657) > (const_int 1 [0x1]))) "test.c":81:8 -1 > (nil)) > (insn 1060 1059 1061 (set (reg:V4HF 657) > (vec_merge:V4HF (vec_duplicate:V4HF (reg:HF 648)) > (reg:V4HF 657) > (const_int 2 [0x2]))) "test.c":81:8 -1 > (nil)) > (insn 1061 1060 1062 (set (reg:V4HF 657) > (vec_merge:V4HF (vec_duplicate:V4HF (reg:HF 654)) > (reg:V4HF 657) > (const_int 4 [0x4]))) "test.c":81:8 -1 > (nil)) > (insn 1062 1061 1063 (set (reg:V4HF 658) > (const_vector:V4HF [ > (const_double:HF 0.0 [0x0.0p+0]) repeated x4 > ])) "test.c":81:8 -1 > (nil)) > (insn 1063 1062 1064 (set (reg:V4HF 658) > (vec_merge:V4HF (vec_duplicate:V4HF (reg:HF 645)) > (reg:V4HF 658) > (const_int 1 [0x1]))) "test.c":81:8 -1 > (nil)) > (insn 1064 1063 1065 (set (reg:V4HF 658) > (vec_merge:V4HF (vec_duplicate:V4HF (reg:HF 651)) > (reg:V4HF 658) > (const_int 2 [0x2]))) "test.c":81:8 -1 > (nil)) > (insn 1065 1064 0 (set (reg:V8HF 641) > (unspec:V8HF [ > (subreg:V8HF (reg:V4HF 657) 0) > (subreg:V8HF (reg:V4HF 658) 0) > ] UNSPEC_ZIP1)) "test.c":81:8 -1 > (nil)) > > It seems to me that the above sequence correctly initializes the > vector into r641 ? > insns 1058-1061 construct r657 = { r642, r648, r654, 0 } > insns 1062-1064 construct r658 = { r645, r651, 0, 0 } > and zip1 will create r641 = { r642, r645, r648, r651, r654, 0, 0, 0 } > > For the above test, it seems that with interleave+zip1 approach and > -fstack-protector-all, > in cse pass, there are two separate equivalence classes created for > (const_int 1), that need > to be merged in cse_insn: > > if (elt->first_same_value != src_eqv_elt->first_same_value) > { > /* The REG_EQUAL is indicating that two formerly distinct > classes are now equivalent. So merge them. */ > merge_equiv_classes (elt, src_eqv_elt); > > elt equivalence chain: > Equivalence chain for (subreg:QI (reg:V16QI 671) 0): > (subreg:QI (reg:V16QI 671) 0) > (const_int 1 [0x1]) > > src_eqv_elt equivalence chain: > Equivalence chain for (const_int 1 [0x1]): > (reg:QI 34 v2) > (reg:QI 32 v0) > (reg:QI 34 v2) > (const_int 1 [0x1]) > (vec_select:QI (reg:V16QI 671) > (parallel [ > (const_int 1 [0x1]) > ])) > (vec_select:QI (reg:V16QI 32 v0) > (parallel [ > (const_int 1 [0x1]) > ])) > (vec_select:QI (reg:V16QI 33 v1) > (parallel [ > (const_int 2 [0x2]) > ])) > (vec_select:QI (reg:V16QI 33 v1) > (parallel [ > (const_int 1 [0x1]) > ])) > > The issue is that merge_equiv_classes doesn't seem to deal correctly with > multiple occurences of same register in class2 (src_eqv_elt), which > has two occurrences of > (reg:QI 34 v2) > > In merge_equiv_classes, on first iteration, it will remove (reg:QI 34) > from reg_equiv_table > by calling delete_equiv_reg(34), and in insert_regs it will create an > entry for (reg:QI 34) in qty_table with new quantity number, and > create new equivalence in reg_eqv_table. > > When we again come across (reg:QI 34) in class2, it will > unconditionally remove the register from reg_eqv_table, thus making > REG_QTY(34) = -35, even tho (reg:QI 34) is now present in class1 > chain. > > Then in insert_regs, we have: > x: (reg:QI 34 v2) > > classp: > (subreg:QI (reg:V16QI 671) 0) > (reg:QI 34 v2) > (const_int 1 [0x1]) > > And while iterating over elements in classp, we end up with regno == > c_regno == 34. > However, as mentioned above, merge_equiv_classes has deleted entry for > (reg:QI 34) from reg_eqv_table, so it's no longer valid, and thus end > up hitting the following assert: > gcc_assert (REGNO_QTY_VALID_P (c_regno)); > > I am not sure tho why this is triggered only with interleave+zip1 approach with > -fstack-protector-all. > > The attached (untested) patch is a workaround for the above issue -- > In merge_equiv_classes, > while iterating over elements in class2, it simply checks if element > is a reg, and already inserted in class1 with equivalent mode, and > avoids deleting it from reg_eqv_table in that case. > > This avoids hitting the assert, and following is the result of merging > above two classes: > Equivalence chain for (subreg:QI (reg:V16QI 671) 0): > (subreg:QI (reg:V16QI 671) 0) > (reg:QI 34 v2) > (reg:QI 32 v0) > (reg:QI 34 v2) > (const_int 1 [0x1]) > (const_int 1 [0x1]) > (vec_select:QI (reg:V16QI 671) > (parallel [ > (const_int 1 [0x1]) > ])) > (vec_select:QI (reg:V16QI 33 v1) > (parallel [ > (const_int 1 [0x1]) > ])) > (vec_select:QI (reg:V16QI 33 v1) > (parallel [ > (const_int 2 [0x2]) > ])) > (vec_select:QI (reg:V16QI 32 v0) > (parallel [ > (const_int 1 [0x1]) > ])) > > Which seems to be OK (?), but am not sure if this patch is in the > right direction, > and is also not efficient. > Could you please suggest how to proceed ? Hi, ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637913.html Thanks, Prathamesh > > Thanks, > Prathamesh