From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27109 invoked by alias); 31 Jan 2014 19:43:41 -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 27097 invoked by uid 89); 31 Jan 2014 19:43:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 31 Jan 2014 19:43:38 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 812A675072; Fri, 31 Jan 2014 19:43:35 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: References: <52EBC010.5030409@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: RE: No TBAA before ptr_derefs_may_alias_p? From: Richard Biener Date: Fri, 31 Jan 2014 21:32:00 -0000 To: Bingfeng Mei ,"gcc@gcc.gnu.org" Message-ID: <783352a3-eb4d-467a-82bd-8cca90f74a30@email.android.com> X-SW-Source: 2014-01/txt/msg00343.txt.bz2 On January 31, 2014 6:01:36 PM GMT+01:00, Bingfeng Mei wrote: >Unfortunately this patch doesn't work because the memory dependency is >Anti in this >case. > >Why TBAA cannot handle anti- & output- dependencies? I check GCC bug >database, and >found pr38503 & pr38964. I don't fully understand it, but seems to me >is related >in handling C++ new operator. But this example is pretty clear and has >nothing to >do with C++ and new statement. Isn't it too conservative to disable >TBAA for anti- >& output- dependency here? Because the gcc memory model allows the dynamic type of a memory location to change by a store. That in turn is the only sensible way of supporting c++ placement new. Richard. > >Bingfeng > >-----Original Message----- >From: Richard Biener [mailto:rguenther@suse.de] >Sent: 31 January 2014 15:24 >To: Bingfeng Mei; gcc@gcc.gnu.org >Subject: Re: No TBAA before ptr_derefs_may_alias_p? > >On 1/31/14 4:02 PM, Bingfeng Mei wrote: >> Hi, >> I got this simple example to vectorize. Somehow, GCC (4.8) generates >loop version because >> it cannot determine alias between acc[i] write and x[i].real read. It >is pretty obvious to me that they are not aliased based on TBAA >information. >> >> typedef struct >> { >> short real; >> short imag; >> } complex16_t; >> >> void >> libvector_AccSquareNorm_ref (unsigned long long *acc, >> const complex16_t *x, unsigned len) >> { >> for (unsigned i = 0; i < len; i++) >> { >> acc[i] += >> ((unsigned long long)((int)x[i].real * x[i].real)) + >> ((unsigned long long)((int)x[i].imag * x[i].imag)); >> } >> } >> >> Tracing into how the alias information is calculated, I found it hits >the following code >> by calling ptr_derefs_may_alias_p and return true. >ptr_derefs_may_alias_p doesn't contain >> TBAA disambiguation code. Should we add check before that? >> >> /* If we had an evolution in a MEM_REF BASE_OBJECT we do not know >> the size of the base-object. So we cannot do any offset/overlap >> based analysis but have to rely on points-to information only. >*/ >> if (TREE_CODE (addr_a) == MEM_REF >> && DR_UNCONSTRAINED_BASE (a)) >> { >> if (TREE_CODE (addr_b) == MEM_REF >> && DR_UNCONSTRAINED_BASE (b)) >> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0), >> TREE_OPERAND (addr_b, 0)); >> else >> return ptr_derefs_may_alias_p (TREE_OPERAND (addr_a, 0), >> build_fold_addr_expr (addr_b)); >> } >> else if (TREE_CODE (addr_b) == MEM_REF >> && DR_UNCONSTRAINED_BASE (b)) >> return ptr_derefs_may_alias_p (build_fold_addr_expr (addr_a), >> TREE_OPERAND (addr_b, 0)); >> >> /* Otherwise DR_BASE_OBJECT is an access that covers the whole >object >> that is being subsetted in the loop nest. */ >> if (DR_IS_WRITE (a) && DR_IS_WRITE (b)) >> return refs_output_dependent_p (addr_a, addr_b); >> else if (DR_IS_READ (a) && DR_IS_WRITE (b)) >> return refs_anti_dependent_p (addr_a, addr_b); >> return refs_may_alias_p (addr_a, addr_b); >> >> This issue can be reproduced on trunk x86-64 gcc. > >True, you can add a > > if (flag_strict_aliasing > && DR_IS_WRITE (a) && DR_IS_READ (b) > && !alias_sets_conflict_p (get_alias_set (DR_REF (a)), get_alias_set >(DR_REF (b))) > return false; > >before the ptr_derefs_may_alias_p calls. TBAA is only valid for >true dependences. > >Richard. > >> Cheers, >> Bingfeng Mei >>