From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31364 invoked by alias); 7 Jul 2014 14:48:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 31344 invoked by uid 89); 7 Jul 2014 14:48:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f179.google.com Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com) (74.125.82.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 07 Jul 2014 14:48:10 +0000 Received: by mail-we0-f179.google.com with SMTP id w62so4509271wes.24 for ; Mon, 07 Jul 2014 07:48:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.195.12.97 with SMTP id ep1mr16897055wjd.26.1404744487202; Mon, 07 Jul 2014 07:48:07 -0700 (PDT) Received: by 10.195.11.202 with HTTP; Mon, 7 Jul 2014 07:48:07 -0700 (PDT) In-Reply-To: References: <53ADCE45.3010306@redhat.com> <53B18841.8060809@redhat.com> <53BAACC5.5010301@redhat.com> Date: Mon, 07 Jul 2014 14:48:00 -0000 Message-ID: Subject: Re: [PATCH, alpha]: Wrap {un,}aligned_store sequence with memory blockages. From: Richard Biener To: Richard Henderson Cc: Uros Bizjak , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00470.txt.bz2 On Mon, Jul 7, 2014 at 4:34 PM, Richard Biener wrote: > On Mon, Jul 7, 2014 at 4:20 PM, Richard Henderson wrote: >> On 07/07/2014 02:10 AM, Richard Biener wrote: >>> On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson wrote: >>>> On 06/29/2014 11:14 AM, Uros Bizjak wrote: >>>>> if (MEM_READONLY_P (x)) >>>>> + if (GET_CODE (mem_addr) == AND) >>>>> + return 1; >>>>> return 0; >>>> >>>> Certainly missing braces here. But with that fixed the patch looks plausible. >>>> I'll look at it closer later today. >>> >>> Umm... but certainly a very gross hack for a special target in a very >>> general routine. >>> >>> So - please no! >>> >>> If addresses with AND are supposed to be barriers then you should >>> model this explicitely in the IL and not make it work "magically". >> >> Huh? We've supported AND as a conflict-with-most address for like forever. >> It's not just Alpha that uses them either; at least Altivec as well. > > Ugh. I wasn't aware of that - is this documented anywhere? What > exactly does such address conflict with? Does it inhibit type-based analysis? > > Where do those ANDs come from? If there were a target where > ANDs would be valid part of addresses in memory accesses but > they wouldn't impose such barriers how'd we deal with that > (altivec aligned (masked) loads come to my mind - I don't see why > they would conflict with more than they say). > > Btw, if the mem is MEM_READONLY_P how can it be part of > a {un}aligned_store sequence? Looking at the testcase I see how we might mishandle RMW ops here (but still fail to see why MEM_READONLY_P should be an issue). There is an old bug where this sort of thing triggers on x86_64 as well from generic expansion of block copies IIRC where we store with a word_mode sequence but fail to use a smaller mode for the last piece (PR36043 if I remember correctly). As for the alias issue it would be nice if the RTL alias oracle would be able to early out if memrefs_conflict_p would detect a must-alias. Richard. > Richard. > >>> Maybe use ALIAS_SET_MEMORY_BARRIER instead? >> >> r~ >>