From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 3886B3858413; Wed, 31 Aug 2022 18:53:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3886B3858413 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27VIl5HM029369; Wed, 31 Aug 2022 18:53:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : from : to : cc : references : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=ZAoBDVA8HT/4mlbB3VHA9GfL15wUJp2/tnkMIAP65J4=; b=RO51CouG8zLaK5wJJ6dq+mEkXsGR0tUcph4TSwODDVvXytqJgSlhTsA1JGEJiENKNvZN VygX3N3fU+PESxxGrzI075JncJRlKUc95xH3QVQKIebWyDyv6fxn5F7phPA0s0Mcbfnd ohyKB55SvPp83rU+QUdrX7lYqEglgID4BZafRkrAeMC2QI9fS/w3enHBnpvUHnzv+YxX xjBe6mCp++xmmu8lTGLDLJCwObOaZscZFbOe2ZgVQ81Zb9MRFTHdppfcCU3pw4a7gJxV cQLfmSfcIoM4qcW1WWyADHg5K3QjYfmrJMXX0WWAwTieNlJpRWa5w0KfSDbZkxn/YX2p mQ== Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jad7srh9n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Aug 2022 18:53:51 +0000 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27VIqViP020152; Wed, 31 Aug 2022 18:53:50 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma02wdc.us.ibm.com with ESMTP id 3j7aw9m5jb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Aug 2022 18:53:50 +0000 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27VIrnxt14877394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 Aug 2022 18:53:49 GMT Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 05A01BE054; Wed, 31 Aug 2022 18:59:24 +0000 (GMT) Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7A152BE04F; Wed, 31 Aug 2022 18:59:23 +0000 (GMT) Received: from [9.160.4.32] (unknown [9.160.4.32]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 31 Aug 2022 18:59:23 +0000 (GMT) Message-ID: <6cf4ceb2-9deb-93b4-bd94-ab08c08eb330@linux.ibm.com> Date: Wed, 31 Aug 2022 13:53:48 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322] Content-Language: en-US From: Peter Bergner To: "Kewen.Lin" Cc: GCC Patches , Segher Boessenkool References: <9c6a44db-1239-466a-2990-42207b7eb264@linux.ibm.com> In-Reply-To: <9c6a44db-1239-466a-2990-42207b7eb264@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: dzYZwP9RwHJqBYeXvarshgf6k1QIkBgG X-Proofpoint-GUID: dzYZwP9RwHJqBYeXvarshgf6k1QIkBgG X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-31_11,2022-08-31_03,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxscore=0 malwarescore=0 adultscore=0 bulkscore=0 suspectscore=0 impostorscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208310086 X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,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 8/31/22 8:59 AM, Peter Bergner wrote: > On 8/31/22 4:22 AM, Kewen.Lin wrote: >> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote: >>> - tree src_type = TREE_TYPE (src_ptr); >>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC) >>> + ? build_pointer_type (vector_quad_type_node) >>> + : build_pointer_type (vector_pair_type_node); >> >> Nit: it seems we can use existing ptr_vector_quad_type_node and ptr_vector_pair_type_node? >> I assume the const qualifier is fine since it's for disassembling. > > That's actually what I started with, but I got some type of gimple > verification error which I can't remember what it said. Let me put > that back temporarily and I'll grab the error message. ...and of course, now I can't recreate that issue at all and the ptr_vector_*_type use work fine now. Strange! ...so ok, changed. Maybe the behavior changed since my PR106017 fix went in??? >>> + if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type) >> >> This line looks unexpected, the former is type char while the latter is type __vector_pair *. >> >> I guess you meant to compare the type of pointer type like: >> >> TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (src_type) > > Maybe? However, if that is the case, how can it be working for me? > Let me throw this in the debugger and verify the types and I'll report > back with what I find. Ok, you are correct. Thanks for catching that! I don't think we need those matching outer TREE_TYPE() uses. I think just a simple: if (TREE_TYPE (src_ptr) != src_type) ...should suffice. >> or even with mode like: >> >> TYPE_MODE (TREE_TYPE (TREE_TYPE (src_ptr))) != TYPE_MODE (TREE_TYPE (src_type)) I'd rather not look at the mode here, since OOmode/XOmode doesn't necessarily mean __vector_{pair,quad}, so I'll go with the modified test above. >>> + src_ptr = build1 (VIEW_CONVERT_EXPR, src_type, src_ptr); >> >> Nit: NOP_EXPR seems to be better suited here for pointer conversion. Ok, this works too, so code changed to use it. Thanks! Question for my own education, when would you use VIEW_CONVERT_EXPR over NOP_EXPR? FYI, here is the current code patch with all of the suggested changes incorporated: diff --git a/gcc/config/rs6000/rs6000-builtin.cc b/gcc/config/rs6000/rs6000-builtin.cc index 12afa86854c..61352fcd801 100644 --- a/gcc/config/rs6000/rs6000-builtin.cc +++ b/gcc/config/rs6000/rs6000-builtin.cc @@ -1085,7 +1085,11 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator *gsi, unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2; tree dst_ptr = gimple_call_arg (stmt, 0); tree src_ptr = gimple_call_arg (stmt, 1); - tree src_type = TREE_TYPE (src_ptr); + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC) + ? ptr_vector_quad_type_node : ptr_vector_pair_type_node; + if (TREE_TYPE (src_ptr) != src_type) + src_ptr = build1 (NOP_EXPR, src_type, src_ptr); + tree src = create_tmp_reg_or_ssa_name (TREE_TYPE (src_type)); gimplify_assign (src, build_simple_mem_ref (src_ptr), &new_seq); I'll fire off a new round of bootstrap and regtesting and resubmit if it's clean. Thanks for the review! Peter