From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9373 invoked by alias); 27 May 2018 15:59:56 -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 9360 invoked by uid 89); 27 May 2018 15:59:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KAM_MANYTO,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*f:sk:87a7smb, H*i:sk:87a7smb X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 May 2018 15:59:54 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6E4824024F; Sun, 27 May 2018 15:59:52 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-11.rdu2.redhat.com [10.10.112.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9B28960BE0; Sun, 27 May 2018 15:59:33 +0000 (UTC) Subject: Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP To: Steve Ellcey , Alan.Haward@arm.com, "Richard Earnshaw (lists)" , Francesco Petrogalli , James Greenhalgh , "Sekhar, Ashwin" , gcc , Marcus Shawcroft , nd , richard.sandiford@linaro.org References: <1518212868.14236.47.camel@cavium.com> <32617133-64DC-4F62-B7A0-A6B417C5B14E@arm.com> <1526487700.29509.6.camel@cavium.com> <1526491802.29509.19.camel@cavium.com> <87a7sznw5c.fsf@linaro.org> <1527184223.22014.13.camel@cavium.com> <87a7smbuej.fsf@linaro.org> From: Jeff Law Openpgp: preference=signencrypt Autocrypt: addr=law@redhat.com; prefer-encrypt=mutual; keydata= xsBNBFkbIO8BCACVIqDhDVh9ur8C+zNV1J/cXfwvVDAUcphDEFl4jyHqZORK4Pd3Db8oWqLm Q8lOCr/VOS7lrCtdpVMQkLGOGA16oJ8g7hzhnojpjY09UjsoUiG7oKacuxj8skfp6SIx93Zl +iNYPRa4S+za6nY8qiVjyUuiyX04ZPZMrKp2c2sGi+HnBKUZXGhrz/Jdzdox3tjajWZnObyy nhEN6hn9L3KawTtGPE/R6A/1RhHTD9FQmIWIeucpaY5c6GNKXTFpj2VYx57LY5hve1R5vhrJ IZcgwZAiOtmik5lVi96glY5h6bugRwpexjhwORTLPBCkwiYotSxX99mWd6EHL576i5CNABEB AAHNGUplZmYgTGF3IDxsYXdAcmVkaGF0LmNvbT7CwI4EEwEIADgWIQR+niGjtnP5P/8PpRq8 fP682pgzWwUCWRsg7wIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRC8fP682pgzW5QG B/9VATJmx5235RB+8jiDYGXQf3vd9gBfPy/l1tsaK400eFAevDzfGvKmeCKe+uGnlrH3vyT8 rg9zqH+s5a1Y+lDXPOpJAFmmzbOLU4FW4ucbawmtYvBL65PqpQneCTYnC802/OAcxjm/Onem HlgeK6WicNsBTPwYN/0araDFUejyYBIFi9CNqqflwk5Z3brKbQ9bAYIkysVLC/c3njKPmM0c WPFHG91ubLbWCHwTIK0+mAL714eTD74dXzOjO2ZDBPLGlFN/kO3+YjaO6UOD2O8acvAMCivT kWLr7JwRgLIQDN2DkhQDd3LTPqQE/yOcMcXBTO+fxm8KG0iKQBqWMyGJzsBNBFkbIO8BCACy qbOsv7XegSeea8XORt5zMaBVWKoSyhmmcCmlxZFS2cuYOBt79MO13lZE2DlO3Lv5IKikj/D4 ketGVO4+h5psEMH5Yz5P8bx0TmgwbK1GxPZrzeXozUFJDvvCDbIlT0v0pwUXuK3hg8Ieo2h5 uTed/cn1OjySXW5BqLxN0cyr5hL+J6dcsHvKLT/N3nTgCQhoJXK2MrEMhAGgF3jKpMn3CoS4 i/ZbNI2MQR6LWHwdZ95f0fI8NzHSfVzeLtzCKQec7nr9fgd6Ylk1ZpGWQUPlQmKjzYgeCeTK NO04cwt20WIrQWeWiZFPA0U86NDBdSBrYp4kG3dfIXE+wSSvE7qPABEBAAHCwHYEGAEIACAW IQR+niGjtnP5P/8PpRq8fP682pgzWwUCWRsg7wIbDAAKCRC8fP682pgzW3REB/9cT7iKRPg/ OK9bpLlllIEDM90IaKC79DQrv+fRudOR78cdV4XUwPSFnyHUsP3VJ4lDy5FhiKCwGie0BK53 EsxgMrLy1L8hboFdTE4Vi0xzCheMaMVp4hATDU29k1cuxu1VPpCa8E3mYeHjNV7ip0HN5L4D rfs8lRPJE/oM1vGs9DgQFZrCPPNRNGKC97BH+DHccesEJr7tSsQrkPkt0z/FTKr5wIM02vSx OJjgmcVbGB7dc2j/Sx8loXmuKnuKtM35668kUG8jeJvSQk3o/VHpD27bhl0rR68R2jN6G6kQ egMVb6dPu1Ius8rBE5rFw88J4JEb5q4hMNClWWUFHIdP Message-ID: Date: Sun, 27 May 2018 15:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <87a7smbuej.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00253.txt.bz2 On 05/26/2018 04:09 AM, Richard Sandiford wrote: > Steve Ellcey writes: >> On Wed, 2018-05-16 at 22:11 +0100, Richard Sandiford wrote: >>>   >>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED is the only current way >>> of saying that an rtl instruction preserves the low part of a >>> register but clobbers the high part.  We would need something like >>> Alan H's CLOBBER_HIGH patches to do it using explicit clobbers. >>> >>> Another approach would be to piggy-back on the -fipa-ra >>> infrastructure >>> and record that vector PCS functions only clobber Q0-Q7.  If -fipa-ra >>> knows that a function doesn't clobber Q8-Q15 then that should >>> override >>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED.  (I'm not sure whether it does >>> in practice, but it should :-)  And if it doesn't that's a bug that's >>> worth fixing for its own sake.) >>> >>> Thanks, >>> Richard >> >> Alan, >> >> I have been looking at your CLOBBER_HIGH patches to see if they >> might be helpful in implementing the ARM SIMD Vector ABI in GCC. >> I have also been looking at the -fipa-ra flag and how it works. >> >> I was wondering if you considered using the ipa-ra infrastructure >> for the SVE work that you are currently trying to support with  >> the CLOBBER_HIGH macro? >> >> My current thought for the ABI work is to mark all the floating >> point / vector registers as caller saved (the lower half of V8-V15 >> are currently callee saved) and remove >> TARGET_HARD_REGNO_CALL_PART_CLOBBERED. >> This should work but would be inefficient. >> >> The next step would be to split get_call_reg_set_usage up into >> two functions so that I don't have to pass in a default set of >> registers.  One function would return call_used_reg_set by >> default (but could return a smaller set if it had actual used >> register information) and the other would return regs_invalidated >> by_call by default (but could also return a smaller set). >> >> Next I would add a 'largest mode used' array to call_cgraph_rtl_info >> structure in addition to the current function_used_regs register >> set. >> >> Then I could turn the get_call_reg_set_usage replacement functions >> into target specific functions and with the information in the >> call_cgraph_rtl_info structure and any simd attribute information on >> a function I could modify what registers are really being used/invalidated >> without being saved. >> >> If the called function only uses the bottom half of a register it would not >> be marked as used/invalidated.  If it uses the entire register and the >> function is not marked as simd, then the register would marked as >> used/invalidated.  If the function was marked as simd the register would not >> be marked because a simd function would save both the upper and lower halves >> of a callee saved register (whereas a non simd function would only save the >> lower half). >> >> Does this sound like something that could be used in place of your  >> CLOBBER_HIGH patch? > > One of the advantages of CLOBBER_HIGH is that it can be attached to > arbitrary instructions, not just calls. The motivating example was > tlsdesc_small_, which isn't treated as a call but as a normal > instruction. (And I don't think we want to change that, since it's much > easier for rtl optimisers to deal with normal instructions compared to > calls. In general a call is part of a longer sequence of instructions > that includes setting up arguments, etc.) Yea. I don't think we want to change tlsdesc*. Representing them as normal insns rather than calls seems reasonable to me. Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff. When we left things I think we were trying to decide between CLOBBER_HIGH and clobbering the appropriate subreg. The problem with the latter is the dataflow we compute is inaccurate (overly pessimistic) so that'd have to be fixed. Jeff