Message ID | edc970c5-024a-4466-a0fe-9d237b9316c2@linux.ibm.com |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp1304733dyi; Thu, 11 Jan 2024 00:30:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IE98LQ0+rm5X54z25kOCFCkvO/D/C02SFSxanxgoGiGBczQFIo+186R5bPfOJCHCJ7EbYfA X-Received: by 2002:a05:6214:f27:b0:680:d227:f3fe with SMTP id iw7-20020a0562140f2700b00680d227f3femr858748qvb.50.1704961819177; Thu, 11 Jan 2024 00:30:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1704961819; cv=pass; d=google.com; s=arc-20160816; b=cHoOQOYFw5cGUdqIjSrqWDWIhFt3IZdTBOECbEmoqwG7968FZZgBhM3JnDSCh5BOxs iiGoY7kaNFrzUFGn+loMafpVzKcmez6zRMI37BUeSmNpp8aJ3unoZ7yDKXnvV+vyiGW0 IP4UhN1sGe7zQJ1G5sJKrvz+iVYRr/zXT0NFbwHCuK8swctHSd3k+M+PzAyR8SgfAzbD vpG54Nl0a26Vr+PCRunchfBIit4gTerrNVce0IcdzWZNfNLAV+CXnSbNyUG/n2h9mW4z wxOdGGkD2t2wXaUEP9Ligfgn9BusCDNXuqBWF7dxdfXuipsaDBlmTSBk4kd5e4ypIXhr 1b9Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :subject:from:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature:arc-filter:dmarc-filter:delivered-to; bh=fehbQ0OtlN1NFXZWQADq1FTiiugOU6JwOS8T+HtTyaY=; fh=3eUSxJU+9IWNwGHlMjnmqDQDnJfeMKAjlglEUO7a4vw=; b=cBbDmFjpE27dyCTPasyk2GmbLPy+ef3BGxiZ7KJCj9V8YjfoInHKHjDL8iHjZN4eAF +zcOEFu8dDK8rNFzV/gdOrqAtlpft/8LrRYOsG0v5aHpH+xP5fHbDLOhsVNPPU7w3nlj 5YkpUIEF2x7HjNiDonXggVP+bbIYmBKAkfI9M1oB2I1vd4P5d7Wn0I/5EwXRlAApoBOr Ef8inahxSbqE3unfF01RrLba9Ln0QWCK5Sgi7j3OhRxMVgwLlskV5LqlQgNy5ndWJCdp FhnW1BfFtbIUCpcXimVhtPuJ1Wo17wTYLiu0IgIlai9whNWnPbCwg/D56Jg6i3GlTIku Lk/A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=qhRJTEXX; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id a4-20020a0ce344000000b0067a9cfb87bcsi353803qvm.331.2024.01.11.00.30.19 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 00:30:19 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=qhRJTEXX; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CFD2F38654B4 for <ouuuleilei@gmail.com>; Thu, 11 Jan 2024 08:30:18 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id EC4BD385E01D for <gcc-patches@gcc.gnu.org>; Thu, 11 Jan 2024 08:29:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC4BD385E01D 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EC4BD385E01D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704961749; cv=none; b=Q1jsD8nMpu6hZpy5NniuSkoQJX2UQVXI8SgF6BkFQSwzZGENBP1bwTznATJi/BWhP0jZpSB43GyfyuS1ppeN7+rcypWVtPA++CDU3WUZ84fItXsVTfOtl+e5TjIfXH4xySh98JOC4sTMIS+4GrJMOfBlMwOkxrrHVeJtQwB5ZBA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704961749; c=relaxed/simple; bh=R56h/WTE4SSL5ye69JJBgddYmvRSfi3g5cHdx6BQ7e4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=lSm2iIhHJmtIXi4Bv93mI2sX4dB1oN/JIHjVolQMp7TF2Hu63DclgdsWBpBABU+Qs8AgzE4GgATztfKMpaOT1aE7quMrkVMbdsUvqooh32bMfQY0L3cEESn85fPQKy/YSwCeqL2Q26Py3II6wVB8HjROrYYRN61jjImdal+vL1E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353723.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 40B83YYD022289; Thu, 11 Jan 2024 08:29:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : to : cc : from : subject : content-type : content-transfer-encoding; s=pp1; bh=fehbQ0OtlN1NFXZWQADq1FTiiugOU6JwOS8T+HtTyaY=; b=qhRJTEXXjg7KyiBzU5d9UzT6iI312z8nBf9wqNFFDgVxo2mGdKPuj1wYk92+0ds+8Uyq /Erh4D3f+on6Dz7KAItAtPCIxQF1QcvfbuKha5NBrqh1bMNQ84CSm23KkqmE0L0rphLO 1awJM+DQEe3CUkZnATiMxtZ+rkpr7U9uMxrA9mUqe5VcVLJvhQOwtGk80bU4W+31KRPO FhczyJashH4Dm6q6eFwcwxBeD4QpuzBqOEcjWlz6DR1KpYh8TlnHIvjbXZhzPKxvL/vF TYNA0aV7nnODZvjM60bWL4xc1e32EWTeJn0c/SgY6SBUEnwirp6wItXdkaKfZnA4hW+I Sg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3vjbgxj10w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2024 08:29:06 +0000 Received: from m0353723.ppops.net (m0353723.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 40B83flZ023153; Thu, 11 Jan 2024 08:29:05 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3vjbgxj10q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2024 08:29:05 +0000 Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 40B67oHF000886; Thu, 11 Jan 2024 08:29:04 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 3vfkdkj1pa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2024 08:29:04 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 40B8T2mU28508900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Jan 2024 08:29:02 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EE69F2004D; Thu, 11 Jan 2024 08:29:01 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8A26C20040; Thu, 11 Jan 2024 08:29:00 +0000 (GMT) Received: from [9.200.103.64] (unknown [9.200.103.64]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 11 Jan 2024 08:29:00 +0000 (GMT) Message-ID: <edc970c5-024a-4466-a0fe-9d237b9316c2@linux.ibm.com> Date: Thu, 11 Jan 2024 16:28:59 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: gcc-patches <gcc-patches@gcc.gnu.org> Cc: Segher Boessenkool <segher@kernel.crashing.org>, David <dje.gcc@gmail.com>, "Kewen.Lin" <linkw@linux.ibm.com>, Peter Bergner <bergner@linux.ibm.com> From: HAO CHEN GUI <guihaoc@linux.ibm.com> Subject: [Patch, rs6000] Eliminate unnecessary byte swaps for block clear on P8 LE [PR113325] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: TKcpy_j-bTdZmmsZUCfeA_LiHTyo2kkq X-Proofpoint-GUID: TVot1pM-9kgkCAl2MUcS8CXgHTOYqvXV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-11_04,2024-01-10_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 spamscore=0 suspectscore=0 impostorscore=0 phishscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401110067 X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787782044749121675 X-GMAIL-MSGID: 1787782044749121675 |
Series |
[rs6000] Eliminate unnecessary byte swaps for block clear on P8 LE [PR113325]
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
HAO CHEN GUI
Jan. 11, 2024, 8:28 a.m. UTC
Hi, This patch eliminates unnecessary byte swaps for block clear on P8 LE. For block clear, all the bytes are set to zero. The byte order doesn't make sense. So the alignment of destination could be set to the store mode size in stead of 1 byte in order to eliminates unnecessary byte swap instructions on P8 LE. The test case shows the problem. Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no regressions. Is this OK for trunk? Thanks Gui Haochen ChangeLog rs6000: Eliminate unnecessary byte swaps for block clear on P8 LE gcc/ PR target/113325 * config/rs6000/rs6000-string.cc (expand_block_clear): Set the alignment of destination to the size of mode. gcc/testsuite/ PR target/113325 * gcc.target/powerpc/pr113325.c: New. patch.diff
Comments
On Thu, Jan 11, 2024 at 9:30 AM HAO CHEN GUI <guihaoc@linux.ibm.com> wrote: > > Hi, > This patch eliminates unnecessary byte swaps for block clear on P8 > LE. For block clear, all the bytes are set to zero. The byte order > doesn't make sense. So the alignment of destination could be set to > the store mode size in stead of 1 byte in order to eliminates > unnecessary byte swap instructions on P8 LE. The test case shows the > problem. > > Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no > regressions. Is this OK for trunk? > > Thanks > Gui Haochen > > ChangeLog > rs6000: Eliminate unnecessary byte swaps for block clear on P8 LE > > gcc/ > PR target/113325 > * config/rs6000/rs6000-string.cc (expand_block_clear): Set the > alignment of destination to the size of mode. > > gcc/testsuite/ > PR target/113325 > * gcc.target/powerpc/pr113325.c: New. > > patch.diff > diff --git a/gcc/config/rs6000/rs6000-string.cc b/gcc/config/rs6000/rs6000-string.cc > index 7f777666ba9..4c9b2cbeefc 100644 > --- a/gcc/config/rs6000/rs6000-string.cc > +++ b/gcc/config/rs6000/rs6000-string.cc > @@ -140,7 +140,9 @@ expand_block_clear (rtx operands[]) > } > > dest = adjust_address (orig_dest, mode, offset); > - > + /* Set the alignment of dest to the size of mode in order to > + avoid unnecessary byte swaps on LE. */ > + set_mem_align (dest, GET_MODE_SIZE (mode) * BITS_PER_UNIT); but the alignment is now wrong which might cause ripple-down wrong-code effects, no? It's probably bad to hide the byte-swapping in the move patterns (I'm just guessing you do that) > emit_move_insn (dest, CONST0_RTX (mode)); > } > > diff --git a/gcc/testsuite/gcc.target/powerpc/pr113325.c b/gcc/testsuite/gcc.target/powerpc/pr113325.c > new file mode 100644 > index 00000000000..4a3cae019c2 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr113325.c > @@ -0,0 +1,9 @@ > +/* { dg-do compile } */ > +/* { dg-options "-O2 -mdejagnu-cpu=power8" } */ > +/* { dg-require-effective-target powerpc_p8vector_ok } */ > +/* { dg-final { scan-assembler-not {\mxxpermdi\M} } } */ > + > +void* foo (void* s1) > +{ > + return __builtin_memset (s1, 0, 32); > +}
Hi Richard, Thanks so much for your comments. >> patch.diff >> diff --git a/gcc/config/rs6000/rs6000-string.cc b/gcc/config/rs6000/rs6000-string.cc >> index 7f777666ba9..4c9b2cbeefc 100644 >> --- a/gcc/config/rs6000/rs6000-string.cc >> +++ b/gcc/config/rs6000/rs6000-string.cc >> @@ -140,7 +140,9 @@ expand_block_clear (rtx operands[]) >> } >> >> dest = adjust_address (orig_dest, mode, offset); >> - >> + /* Set the alignment of dest to the size of mode in order to >> + avoid unnecessary byte swaps on LE. */ >> + set_mem_align (dest, GET_MODE_SIZE (mode) * BITS_PER_UNIT); > > but the alignment is now wrong which might cause ripple-down > wrong-code effects, no? > > It's probably bad to hide the byte-swapping in the move patterns (I'm > just guessing > you do that) Here I just change the alignment of "dest" which is temporary used for move. The orig_dest is untouched and keep the original alignment. The subsequent insns which use orig_dest are not affected. I am not sure if it causes ripple-down effects. Do you mean the dest might be reused later? But I think the alignment is different even though the mode and offset is the same. Looking forward to your advice. Thanks Gui Haochen
On Fri, Jan 12, 2024 at 3:15 AM HAO CHEN GUI <guihaoc@linux.ibm.com> wrote: > > Hi Richard, > Thanks so much for your comments. > > > >> patch.diff > >> diff --git a/gcc/config/rs6000/rs6000-string.cc b/gcc/config/rs6000/rs6000-string.cc > >> index 7f777666ba9..4c9b2cbeefc 100644 > >> --- a/gcc/config/rs6000/rs6000-string.cc > >> +++ b/gcc/config/rs6000/rs6000-string.cc > >> @@ -140,7 +140,9 @@ expand_block_clear (rtx operands[]) > >> } > >> > >> dest = adjust_address (orig_dest, mode, offset); > >> - > >> + /* Set the alignment of dest to the size of mode in order to > >> + avoid unnecessary byte swaps on LE. */ > >> + set_mem_align (dest, GET_MODE_SIZE (mode) * BITS_PER_UNIT); > > > > but the alignment is now wrong which might cause ripple-down > > wrong-code effects, no? > > > > It's probably bad to hide the byte-swapping in the move patterns (I'm > > just guessing > > you do that) > > Here I just change the alignment of "dest" which is temporary used for > move. The orig_dest is untouched and keep the original alignment. The > subsequent insns which use orig_dest are not affected. I am not sure if > it causes ripple-down effects. Do you mean the dest might be reused > later? But I think the alignment is different even though the mode and > offset is the same. If the MEM ends up in the IL then its MEM_ALIGN should be better correct. > Looking forward to your advice. > > Thanks > Gui Haochen
Hi Haochen, on 2024/1/11 16:28, HAO CHEN GUI wrote: > Hi, > This patch eliminates unnecessary byte swaps for block clear on P8 > LE. For block clear, all the bytes are set to zero. The byte order > doesn't make sense. So the alignment of destination could be set to > the store mode size in stead of 1 byte in order to eliminates > unnecessary byte swap instructions on P8 LE. The test case shows the > problem. I agree with Richi's concern, a bytes swap can be eliminated if the bytes swapped result is known as before, one typical case is the vector constant with predicate const_vector_each_byte_same, we can do some optimization for that. BR, Kewen > > Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no > regressions. Is this OK for trunk? > > Thanks > Gui Haochen > > ChangeLog > rs6000: Eliminate unnecessary byte swaps for block clear on P8 LE > > gcc/ > PR target/113325 > * config/rs6000/rs6000-string.cc (expand_block_clear): Set the > alignment of destination to the size of mode. > > gcc/testsuite/ > PR target/113325 > * gcc.target/powerpc/pr113325.c: New. > > patch.diff > diff --git a/gcc/config/rs6000/rs6000-string.cc b/gcc/config/rs6000/rs6000-string.cc > index 7f777666ba9..4c9b2cbeefc 100644 > --- a/gcc/config/rs6000/rs6000-string.cc > +++ b/gcc/config/rs6000/rs6000-string.cc > @@ -140,7 +140,9 @@ expand_block_clear (rtx operands[]) > } > > dest = adjust_address (orig_dest, mode, offset); > - > + /* Set the alignment of dest to the size of mode in order to > + avoid unnecessary byte swaps on LE. */ > + set_mem_align (dest, GET_MODE_SIZE (mode) * BITS_PER_UNIT); > emit_move_insn (dest, CONST0_RTX (mode)); > } > > diff --git a/gcc/testsuite/gcc.target/powerpc/pr113325.c b/gcc/testsuite/gcc.target/powerpc/pr113325.c > new file mode 100644 > index 00000000000..4a3cae019c2 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr113325.c > @@ -0,0 +1,9 @@ > +/* { dg-do compile } */ > +/* { dg-options "-O2 -mdejagnu-cpu=power8" } */ > +/* { dg-require-effective-target powerpc_p8vector_ok } */ > +/* { dg-final { scan-assembler-not {\mxxpermdi\M} } } */ > + > +void* foo (void* s1) > +{ > + return __builtin_memset (s1, 0, 32); > +}
diff --git a/gcc/config/rs6000/rs6000-string.cc b/gcc/config/rs6000/rs6000-string.cc index 7f777666ba9..4c9b2cbeefc 100644 --- a/gcc/config/rs6000/rs6000-string.cc +++ b/gcc/config/rs6000/rs6000-string.cc @@ -140,7 +140,9 @@ expand_block_clear (rtx operands[]) } dest = adjust_address (orig_dest, mode, offset); - + /* Set the alignment of dest to the size of mode in order to + avoid unnecessary byte swaps on LE. */ + set_mem_align (dest, GET_MODE_SIZE (mode) * BITS_PER_UNIT); emit_move_insn (dest, CONST0_RTX (mode)); } diff --git a/gcc/testsuite/gcc.target/powerpc/pr113325.c b/gcc/testsuite/gcc.target/powerpc/pr113325.c new file mode 100644 index 00000000000..4a3cae019c2 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/pr113325.c @@ -0,0 +1,9 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -mdejagnu-cpu=power8" } */ +/* { dg-require-effective-target powerpc_p8vector_ok } */ +/* { dg-final { scan-assembler-not {\mxxpermdi\M} } } */ + +void* foo (void* s1) +{ + return __builtin_memset (s1, 0, 32); +}