From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86738 invoked by alias); 15 May 2019 16:24:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 86623 invoked by uid 89); 15 May 2019 16:24:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 May 2019 16:24:04 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4FGMcMR004938 for ; Wed, 15 May 2019 12:24:01 -0400 Received: from e16.ny.us.ibm.com (e16.ny.us.ibm.com [129.33.205.206]) by mx0a-001b2d01.pphosted.com with ESMTP id 2sgm6xq4v9-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 May 2019 12:24:01 -0400 Received: from localhost by e16.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 May 2019 17:24:01 +0100 Received: from b01cxnp22035.gho.pok.ibm.com (9.57.198.25) by e16.ny.us.ibm.com (146.89.104.203) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 15 May 2019 17:23:56 +0100 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x4FGNtvh28967026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 15 May 2019 16:23:55 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BDDCEAC05B; Wed, 15 May 2019 16:23:55 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5A8B8AC062; Wed, 15 May 2019 16:23:55 +0000 (GMT) Received: from ragesh4.rchland.ibm.com (unknown [9.10.86.76]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 15 May 2019 16:23:55 +0000 (GMT) Subject: Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy To: Michael Matz Cc: Richard Biener , GCC Development , Joseph Myers , Jakub Jelinek , Jeff Law , Segher Boessenkool , David Edelsohn , Bill Schmidt References: <21ca63aa-3838-e2ae-bf6e-39ec1b98dca4@linux.ibm.com> From: Aaron Sawdey Date: Wed, 15 May 2019 16:24:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit x-cbid: 19051516-0072-0000-0000-0000042D6F6C X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00011102; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000285; SDB=6.01203738; UDB=6.00631867; IPR=6.00984665; MB=3.00026906; MTD=3.00000008; XFM=3.00000015; UTC=2019-05-15 16:23:59 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19051516-0073-0000-0000-00004C3B7960 Message-Id: X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00118.txt.bz2 On 5/15/19 9:02 AM, Michael Matz wrote: > On Wed, 15 May 2019, Aaron Sawdey wrote: >> Next question would be how do we move from the existing movmem pattern >> (which Michael Matz tells us should be renamed cpymem anyway) to this >> new thing. Are you proposing that we still have both movmem and cpymem >> optab entries underneath to call the patterns but introduce this new >> memmove_with_hints() to be used by things called by >> expand_builtin_memmove() and expand_builtin_memcpy()? > > I'd say so. There are multiple levels at play: > a) exposal to user: probably a new __builtint_memmove, or a new combined > builtin with a hint param to differentiate (but we can't get rid of > __builtin_memcpy/mempcpy/strcpy, which all can go through the same > route in the middleend) > b) getting it through the gimple pipeline, probably just a new builtin > code, trivial > c) expanding the new builtin, with the help of next items > d) RTL block moves: they are defined as non-overlapping and I don't think > we should change this (essentially they're the reflection of struct > copies in C) > e) how any of the above (builtins and RTL block moves) are implemented: > currently non-overlapping only, using movmem pattern when possible; > ultimately all sitting in the emit_block_move_hints() routine. > > So, I'd add a new method to emit_block_move_hints indicating possible > overlap, disabling the use of move_by_pieces. Then in > emit_block_move_via_movmem (alse getting an indication of overlap), do the > equivalent of: > > finished = 0; > if (overlap_possible) { > if (optab[movmem]) > finished = emit(movmem) > } else { > if (optab[cpymem]) > finished = emit(cpymem); > if (!finished && optab[movmem]) // can use movmem also for overlap > finished = emit(movmem); > } > > The overlap_possible method would only ever be used from the builtin > expansion, and never from the RTL block move expand. Additionally a > target may optionally only define the movmem pattern if it's just as good > as the cpymem pattern (e.g. because it only handles fixed small sizes and > uses a load-all then store-all sequence). We currently have gimple_fold_builtin_memory_op() figuring out where there is no overlap and converging __builtin_memmove() to __builtin_memcpy(). Would you forsee looking for converting __builtin_memmove() with overlap into a call to __builtin_memmove_hint if it is a case where we can define the overlap precisely enough to provide the hint? My guess is that this wouldn't be a very common case. My goals for this are: * memcpy() call becomes __builtin_memcpy and goes to optab[cpymem] * memmove() call becomes __builtin_memmove (or __builtin_memcpy based on the gimple analysis) and goes through optab[movmem] or optab[cpymem] I think what you've described meets these goals and cleans things up. Thanks, Aaron -- Aaron Sawdey, Ph.D. acsawdey@linux.vnet.ibm.com 050-2/C113 (507) 253-7520 home: 507/263-0782 IBM Linux Technology Center - PPC Toolchain