From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6596 invoked by alias); 10 Jan 2019 09:24:59 -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 6584 invoked by uid 89); 10 Jan 2019 09:24:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=grave, commercial, deeply, Latest X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 09:24:54 +0000 Received: by mail-wr1-f68.google.com with SMTP id q18so10476864wrx.9 for ; Thu, 10 Jan 2019 01:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6bk1BYw/9bwZGgXo8gbNRXOv/SlnccLGc/BjgSedfC4=; b=f3+cwFUdeWng/YrqmHp8zjkubvgKH0qBau0oLinF2hD2jmoQ6Eo4Y7CR92jEPVSN3w PgpZGCENkxbmDahOgTeaGsOsqHHsdv//0K/7sqfWZ+PScQlZPPOnVlsHOp4MWdYJspdF IylLoLb5aztx9DIAq9NLb14NQJCJLBGydf1Es5yxSz94r6xl6xHh0inhdcjQXIwQL4YY PCLqvQNJY+0CBMBpscGfdF66AzxKbX69fFZ5EFd8MmsVkwoWKX1WvbLWZjsADzMlluPs Tay1j6mRtKWZSlZW7jVv5hcepn0rVnwNANUH8qugGGe2LdET/UGBXIMkZLdUDz9Rwyo2 pz4w== Return-Path: Received: from [192.168.178.20] (p5DDEE0B9.dip0.t-ipconnect.de. [93.222.224.185]) by smtp.googlemail.com with ESMTPSA id k135sm18621643wmd.42.2019.01.10.01.24.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jan 2019 01:24:51 -0800 (PST) Subject: Re: autovectorization in gcc To: Andrew Haley , Kyrill Tkachov , "gcc@gcc.gnu.org" References: <41ea83cd-0ce8-4f25-35e5-888513d69c7b@gmail.com> <5C35C2C2.1050106@foss.arm.com> <2721bb39-ee4b-0202-d81d-e0b36d2059fa@redhat.com> From: "Kay F. Jahnke" Message-ID: Date: Thu, 10 Jan 2019 09:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2721bb39-ee4b-0202-d81d-e0b36d2059fa@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-01/txt/msg00065.txt.bz2 On 09.01.19 10:50, Andrew Haley wrote: > On 1/9/19 9:45 AM, Kyrill Tkachov wrote: >> There's plenty of work being done on auto-vectorisation in GCC. >> Auto-vectorisation is a performance optimisation and as such is not really >> a user-visible feature that absolutely requires user documentation. > > I don't agree. Sometimes vectorization is critical. It would be nice > to have a warning which would fire if vectorization failed. That would > surely help the OP. Further down this thread, some g++ flags were used which produced meaningful information about vectorization failures, so the facility is there - maybe it's not very prominent. When it comes to user visibility, I'd like to add that there are great differences between different users. I spend most of my time writing library code, using template metaprogramming in C++. It's essential for my code to perform well (real-time visualization), but I don't have intimate compiler knowledge - I'm aiming at writing portable, standard-compliant code. I'd like the compilers I use to provide extensive documentation if I need to track down a problem, and I dislike it if I have to use 'special' commands to get things done. Other users may produce target-specific code with one specific compiler, and they have different needs. It's better to have documentation and not need it than the other way round. So my idea of a 'contract' regarding vectorization is like this: - the documentation states the scope of vectorization - the use of a feature can be forced or disallowed - or left up to a cost model - the compiler can be made to produce diagnostic output Documentation is absolutely essential. If there is lots of development in autovectorization, not documenting this work in a way users can simply find is - in my eyes - a grave omission. The text 'Auto-vectorization in GCC' looks like it has last been updated in 2011 (according to the 'Latest News' section). I'm curious to know what new capabilities have been added since then. It makes my life much easier if I can write loops to follow a given pattern relying on the autovectorizer, rather than having to use explicit vector code, having to rely on a library. There is also another aspect to being dependent on external libraries. When a new architecture comes around, chances are the compiler writers will be first to support it. It may take years for an external library to add a new target ISA, more time until this runs smoothly, and then more time until it has trickled down to the package repos of most distributions - if this happens at all. Plus you have the danger of betting on the wrong horse, and when the very promising library you've used to code your stuff goes offline or commercial, you've wasted your precious time. Relying only on the compiler brings innovation out most reliably and quickly, and is a good strategy to avoid wasting resources. Now I may be missing things here because I haven't dug deeply enough to find documentation about autovectorization in gcc. This was why I have asked to be pointed to 'where the action is'. I was hoping to maybe get some helpful hints. My main objective is, after all, to 'deliberately exploit the compiler's autovectorization facilities by feeding data in autovectorization-friendly loops'. The code will run, vectorized or not, but it would be great to have good guidelines what will or will not be autovectorized with a given compiler, rather than having to look at the assembler output. Kay