[{"id":1768932,"web_url":"http://patchwork.ozlabs.org/comment/1768932/","msgid":"","list_archive_url":null,"date":"2017-09-15T03:36:47","subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","submitter":{"id":40,"url":"http://patchwork.ozlabs.org/api/people/40/","name":"Andrew Pinski","email":"pinskia@gmail.com"},"content":"On Thu, Sep 14, 2017 at 6:33 PM, Kugan Vivekanandarajah\n wrote:\n> This patch adds aarch64_loop_unroll_adjust to limit partial unrolling\n> in rtl based on strided-loads in loop.\n\nCan you expand on this some more? Like give an example of where this\nhelps? I am trying to better understand your counting schemes since\nit seems like the count is based on the number of loads and not cache\nlines.\n\nWhat do you mean by a strided load?\nDoesn't this function overcount when you have:\nfor(int i = 1;i<1024;i++)\n {\n t+= a[i-1]*a[i];\n }\nif it is counting based on cache lines rather than based on load addresses?\n\nIt also seems to do some weird counting when you have:\nfor(int i = 1;i<1024;i++)\n {\n t+= a[(i-1)*N+i]*a[(i)*N+i];\n }\n\nThat is:\n(PLUS (REG) (REG))\n\nAlso seems to overcount when loading from the same pointer twice.\n\nIn my micro-arch, the number of prefetch slots is based on cache line\nmiss so this would be overcounting by a factor of 2.\n\nThanks,\nAndrew\n\n>\n> Thanks,\n> Kugan\n>\n> gcc/ChangeLog:\n>\n> 2017-09-12 Kugan Vivekanandarajah \n>\n> * cfgloop.h (iv_analyze_biv): export.\n> * loop-iv.c: Likewise.\n> * config/aarch64/aarch64.c (strided_load_p): New.\n> (insn_has_strided_load): New.\n> (count_strided_load_rtl): New.\n> (aarch64_loop_unroll_adjust): New.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-462195-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"t5Jl6zwz\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xth0d3YBZz9sCZ\n\tfor ;\n\tFri, 15 Sep 2017 13:37:00 +1000 (AEST)","(qmail 85699 invoked by alias); 15 Sep 2017 03:36:52 -0000","(qmail 85668 invoked by uid 89); 15 Sep 2017 03:36:51 -0000","from mail-io0-f176.google.com (HELO mail-io0-f176.google.com)\n\t(209.85.223.176) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tFri, 15 Sep 2017 03:36:50 +0000","by mail-io0-f176.google.com with SMTP id z187so5356078ioz.12 for\n\t; Thu, 14 Sep 2017 20:36:50 -0700 (PDT)","by 10.157.27.244 with HTTP; Thu, 14 Sep 2017 20:36:47 -0700 (PDT)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; q=dns; s=default; b=xNY+favyWdns2X0\n\tLlOuucm77JxHR07hlfofQQ+FPCo+0nAwLxq7yBobZKDK8hw6kRCdF9sNgq976hkx\n\txHaSvdyhkKdZySIuYht2iETISmA2cH7hEx6H20vC/9D+yf/cWLBk92/JSAL2Sprp\n\tYyUCsSShD1Ra1/UJC86Nv4j7k7Is=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; s=default; bh=is8Geu7K/oarNiBrLypNO\n\tx05L8Y=; b=t5Jl6zwzd53Jf5gxEVIhSnYg9lrynqBuOqYQdWq4+5O105PxlhzVw\n\tzvTmxoeNzFtkPLpE41wljkcp2jzALqxMPTM4DOeFmVcQkzH7mF3IAccsJS8SYsJF\n\tTaWyUM5fedgF/FJnF+r69yM6XRFRxP9YOfrLGRNvcxug5lEYR0LB0A=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.8 required=5.0 tests=AWL, BAYES_00,\n\tFREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1431","X-HELO":"mail-io0-f176.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;\n\ts=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=ekmLF0h9eAsRRD7d1FSABU6etxXR5BbN2OD7ovHfFpc=;\n\tb=Q/1WfeMdCD5BonCCldsclj6JfND/XPIt+/g7KTmGEhS+krV59jvgpln4UPh9jIrFHk\n\tKjK32HKdlYORrp6TqF8Swzo3UNss9D1+vU0p2Uq7A0CziWZ4m4S5d2ezcZyt6o/ZpJPm\n\taxRh+TyuFTQAM/qE59RfHRcpvAanLCXZQXO9qB2A/MTF7v0G6pjzhNIqaE6YOTEOTPTd\n\tw+fOnxzht6atPGXPWl61P51085ZanZo4YiHADF9JjNd6hbumL4//GGZYqSjIyz4YsK4h\n\t7Op35jJ0Ti6b/yE21QzuOzGtHr3J0lH4zY+Rg2I0fCbXPifCxCE91NHxyaTYYa9+ZN5C\n\tZxLQ==","X-Gm-Message-State":"AHPjjUgd2SijCfG4w36F8X5S4jsGWGKytgoXm4+fZL2/Cd9a+zjCNOPN\txDTTypDFBy6zHHISXwGK1pAtyC0XZSFyWkZ8g0Q9NA==","X-Google-Smtp-Source":"AOwi7QANFa9wL/cXGs8BIOwkiCd7BM38Jiyl+sASv80pB3e0R1pF8Z6D90kvdF76H0AsLOIr+AcKNVF5WsZehfutrbc=","X-Received":"by 10.202.102.217 with SMTP id m86mr266091oik.309.1505446608184;\n\tThu, 14 Sep 2017 20:36:48 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"","From":"Andrew Pinski ","Date":"Thu, 14 Sep 2017 20:36:47 -0700","Message-ID":"","Subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","To":"Kugan Vivekanandarajah ","Cc":"\"gcc-patches@gcc.gnu.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","X-IsSubscribed":"yes"}},{"id":1769049,"web_url":"http://patchwork.ozlabs.org/comment/1769049/","msgid":"","list_archive_url":null,"date":"2017-09-15T08:40:52","subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","submitter":{"id":4605,"url":"http://patchwork.ozlabs.org/api/people/4605/","name":"Ramana Radhakrishnan","email":"ramana.gcc@googlemail.com"},"content":"On Fri, Sep 15, 2017 at 2:33 AM, Kugan Vivekanandarajah\n wrote:\n> This patch adds aarch64_loop_unroll_adjust to limit partial unrolling\n> in rtl based on strided-loads in loop.\n>\n> Thanks,\n> Kugan\n>\n> gcc/ChangeLog:\n>\n> 2017-09-12 Kugan Vivekanandarajah \n>\n> * cfgloop.h (iv_analyze_biv): export.\n> * loop-iv.c: Likewise.\n> * config/aarch64/aarch64.c (strided_load_p): New.\n> (insn_has_strided_load): New.\n> (count_strided_load_rtl): New.\n> (aarch64_loop_unroll_adjust): New.\n\n\nThis implementation assumes a particular kind of prefetcher and\ncollisions in that hardware prefetcher. Are you sure this helps every\nsingle micro-architecture out there (or rather doesn't harm ?) ?\nFurther more how has this patchset been benchmarked, what\nmicro-architecture, what benchmarks, what's the performance impact and\nwhy should this be considered for generic ?\n\nregards\nRamana","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-462205-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"NwzLeAX5\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtplW2MKMz9s3w\n\tfor ;\n\tFri, 15 Sep 2017 18:41:07 +1000 (AEST)","(qmail 122397 invoked by alias); 15 Sep 2017 08:40:57 -0000","(qmail 122286 invoked by uid 89); 15 Sep 2017 08:40:57 -0000","from mail-lf0-f67.google.com (HELO mail-lf0-f67.google.com)\n\t(209.85.215.67) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tFri, 15 Sep 2017 08:40:55 +0000","by mail-lf0-f67.google.com with SMTP id c8so843467lfe.2 for\n\t; Fri, 15 Sep 2017 01:40:55 -0700 (PDT)","by 10.46.88.90 with HTTP; Fri, 15 Sep 2017 01:40:52 -0700 (PDT)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; q=dns; s=default; b=grPGqclHbexPfMD\n\tDTTqwSDEgye9T2ZepwoTU1IPjfFW7pe4X+RPrc7VbwLIdvPJcYxOIfVNTovoVUEM\n\tcEp2iUeRB/YmldadyQ7Aptx7FKdoyKFxQ8eqhYtXqRpNGBycyTeOL4CuivbAGtg7\n\ta2+LMWJ2eqG37b3jCqIzeBPmXMUM=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; s=default; bh=sNnWLa3fs/ROnZVX4eotl\n\tBhQNJM=; b=NwzLeAX5o47d3TwtvynRdWdqmB8/PpLiMQDIJlsenUGayXrntn6j7\n\tLUkiBHdL7WnrGXhqb5qXk2iXYAVliLFEJy+TnxRb6DYfiXp7uY9ciEnq3uWdNuEl\n\tEb/7ALBWjjPoaPOdeLK3JfZRLZUrR4p0LgJYKjf7EwZrg9DTMI1JD8=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.5 required=5.0 tests=AWL, BAYES_00,\n\tFREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=","X-HELO":"mail-lf0-f67.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;\n\ts=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=JVsewIK9HdQ6t+io6b8WBLdXQSoa8cdW2hPurifn/gk=;\n\tb=ZXqTYqzdtQBC1FWnssMxMPzPESoKJjGZl5DXBBQQMnpx2/Zi6eAQUCV0A8ZplPM3QI\n\tkeU4+Rr47f1E2ohvT8JqFuqhd0+iXGoeIzIaeJR/vidMjzofXnE2WUGFnVrGn7GNg2Bh\n\t/FbKkkyEobwQ6Ho9rwrEsGS36KzzpGBkWgGhI6MuWkVs2tLvQf8BZnOskEyA5SJPYJ8T\n\tDNWjtrX/olllnWfzYABH0WQnEIAdoT8b6/xoZfhieW6sqnvOkW+uN7eY1bTzM6/2J9+6\n\tXSEr40RKeDt7zPM6HkYYu6b6ZHpUGturJUVKbjxAyVsythV/OcrmJ8RAunKuYhOfXxHk\n\tcjDA==","X-Gm-Message-State":"AHPjjUg1mCOBySgcT9AKyYAaiX1wURg9nBlb0PB7zQdfPHsDoDm8B1Hg\tFFS1IONBP55M6VAw9ofWtrzud37up9wPV8IRPCI=","X-Google-Smtp-Source":"AOwi7QBYmigTxbtGxnlInGYNPk3kXOvUrn2wCj9ANWmqs2qO1jHJw715MeKDMS3cE0ISZSdE4E51sLEIoKc+69P53gA=","X-Received":"by 10.25.23.80 with SMTP id n77mr365065lfi.121.1505464853332;\n\tFri, 15 Sep 2017 01:40:53 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"","From":"Ramana Radhakrishnan ","Date":"Fri, 15 Sep 2017 09:40:52 +0100","Message-ID":"","Subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","To":"Kugan Vivekanandarajah ","Cc":"\"gcc-patches@gcc.gnu.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","X-IsSubscribed":"yes"}},{"id":1769653,"web_url":"http://patchwork.ozlabs.org/comment/1769653/","msgid":"","list_archive_url":null,"date":"2017-09-16T22:54:25","subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","submitter":{"id":25768,"url":"http://patchwork.ozlabs.org/api/people/25768/","name":"Kugan Vivekanandarajah","email":"kugan.vivekanandarajah@linaro.org"},"content":"Hi Ramana\n\nOn 15 September 2017 at 18:40, Ramana Radhakrishnan\n wrote:\n> On Fri, Sep 15, 2017 at 2:33 AM, Kugan Vivekanandarajah\n> wrote:\n>> This patch adds aarch64_loop_unroll_adjust to limit partial unrolling\n>> in rtl based on strided-loads in loop.\n>>\n>> Thanks,\n>> Kugan\n>>\n>> gcc/ChangeLog:\n>>\n>> 2017-09-12 Kugan Vivekanandarajah \n>>\n>> * cfgloop.h (iv_analyze_biv): export.\n>> * loop-iv.c: Likewise.\n>> * config/aarch64/aarch64.c (strided_load_p): New.\n>> (insn_has_strided_load): New.\n>> (count_strided_load_rtl): New.\n>> (aarch64_loop_unroll_adjust): New.\n>\n>\n> This implementation assumes a particular kind of prefetcher and\n> collisions in that hardware prefetcher. Are you sure this helps every\n> single micro-architecture out there (or rather doesn't harm ?) ?\n> Further more how has this patchset been benchmarked, what\n> micro-architecture, what benchmarks, what's the performance impact and\n> why should this be considered for generic ?\n>\n\nI tested on -mcpu=falkor and at the moment this does not have any\neffect on other cpus. It is not enabled for generic.\n\nThanks,\nKugan","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-462320-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"Ht5swaSw\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xvnds2Gmnz9t16\n\tfor ;\n\tSun, 17 Sep 2017 08:54:41 +1000 (AEST)","(qmail 127020 invoked by alias); 16 Sep 2017 22:54:34 -0000","(qmail 127007 invoked by uid 89); 16 Sep 2017 22:54:33 -0000","from mail-qk0-f173.google.com (HELO mail-qk0-f173.google.com)\n\t(209.85.220.173) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tSat, 16 Sep 2017 22:54:27 +0000","by mail-qk0-f173.google.com with SMTP id u67so4686037qkg.6 for\n\t; Sat, 16 Sep 2017 15:54:26 -0700 (PDT)","by 10.237.37.211 with HTTP; Sat, 16 Sep 2017 15:54:25 -0700 (PDT)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; q=dns; s=default; b=Vq2gX8Ab8wC1A0f\n\twIS4uD+UWUDSSBedzchJfrCS2or/kgXAwvLYUtO3sxps8NhrlSHFHGVxWDn7CFTM\n\txtKZjM+7+HvUUVTyuecmhY91R+Mv+I7kW1JJBS9fgOMn2DsDSLPUSyXcA5KE3rPS\n\tZxANiMA5MPYSy4N9tUb12dgTN1DA=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; s=default; bh=2fZUwEa+5kc6dvA/CUuo1\n\tNIxs9s=; b=Ht5swaSwbOe1F7Ouu8u4REcXvYyeYjrD8yYJuMr3pFZxhpH7H7wuK\n\tB3+7+KuJ+IWI+Wno3pyT0fbbkaEGebKwt2mJdqkuEEnA9VLi6ANvlt5yDTwOozNU\n\tD/nM7g37qeujQ2CgT2WgwoE0wS0k6ff4e/IeMox7wHKMwjfg2L4evc=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.6 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=","X-HELO":"mail-qk0-f173.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;\n\ts=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=eZ509yAfAxqMTY2NfsNYBj1QFEbBR2wJcH8sC419ZyM=;\n\tb=UKXwfsV7ISN0XQAFEz0QrA5WGI+/w1A2dxz0nIGePrnCBQ0wgs0vTQpzMPQgYniCG0\n\tX1qvVLrxO383sZFC4NQGbZU5xF7w6EX1CUoc1T4oCfYn1K6inxyJdUm4IPbFwt48v+tw\n\tMhmtjfEHHCdnO/vySoJ6DAm/yTiH6YLzqher1PYzwaAsc18PH0XsyA/Sp+7rGyvAD4cM\n\tj6HI07iHatAw1xnWJEN8ElkNt92bKatsEoDeUbB0TWPlNCa9dtG+ITR9brXVQKPBhPYS\n\t8rWnJqpTm7UbyJsCuBSW0fQadzWnKAS47aryiNrhX2C8ysdpOhccH3SZz2zHgpQNQnq9\n\tmiog==","X-Gm-Message-State":"AHPjjUgowpoOnkdcS9Xty9T+o7lRoyqeNWo9smedwCayE2airO9DQyoG\tDcHTwPUcvKoe20g09M9zHphOqNcsIjIPaqfkFKSqa5nf","X-Google-Smtp-Source":"AOwi7QCgIk9MehgTrAhXq3d20bl8PQjeh9cIYuxrFI2fThCYVrPNHKL67jtvAKvfe9KwEZaQimBB2Yh79Th9lFzn7y8=","X-Received":"by 10.55.104.131 with SMTP id d125mr13510343qkc.37.1505602465537;\n\tSat, 16 Sep 2017 15:54:25 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"\n\t","From":"Kugan Vivekanandarajah ","Date":"Sun, 17 Sep 2017 08:54:25 +1000","Message-ID":"","Subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","To":"Ramana Radhakrishnan ","Cc":"\"gcc-patches@gcc.gnu.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","X-IsSubscribed":"yes"}},{"id":1769822,"web_url":"http://patchwork.ozlabs.org/comment/1769822/","msgid":"","list_archive_url":null,"date":"2017-09-17T23:41:37","subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","submitter":{"id":25768,"url":"http://patchwork.ozlabs.org/api/people/25768/","name":"Kugan Vivekanandarajah","email":"kugan.vivekanandarajah@linaro.org"},"content":"Hi Andrew,\n\nOn 15 September 2017 at 13:36, Andrew Pinski wrote:\n> On Thu, Sep 14, 2017 at 6:33 PM, Kugan Vivekanandarajah\n> wrote:\n>> This patch adds aarch64_loop_unroll_adjust to limit partial unrolling\n>> in rtl based on strided-loads in loop.\n>\n> Can you expand on this some more? Like give an example of where this\n> helps? I am trying to better understand your counting schemes since\n> it seems like the count is based on the number of loads and not cache\n> lines.\n\nThis is a simplified model and I am assuming here that prefetcher will\ntune based on the memory accesses. I don't have access to any of the\ninternals of how this is implemented in different microarchitectures\nbut I am assuming (in a simplified sense) that hw logic will detect\nmemory accesses patterns and using this it will prefetch the cache\nline. If there are memory accesses like what you have shown that falls\nwithin the cache line, they may be combined but you still need to\ndetect them and tune. And also detecting them at compile time is not\nalways easy. So this is a simplified model.\n\n> What do you mean by a strided load?\n> Doesn't this function overcount when you have:\n> for(int i = 1;i<1024;i++)\n> {\n> t+= a[i-1]*a[i];\n> }\n> if it is counting based on cache lines rather than based on load addresses?\nSorry for my terminology. what I mean by strided access is any memory\naccesses in the form memory[iv]. I am counting memory[iv] and\nmemory[iv+1] as two deferent streams. This may or may not fall into\nsame cache line.\n\n>\n> It also seems to do some weird counting when you have:\n> for(int i = 1;i<1024;i++)\n> {\n> t+= a[(i-1)*N+i]*a[(i)*N+i];\n> }\n>\n> That is:\n> (PLUS (REG) (REG))\n>\n> Also seems to overcount when loading from the same pointer twice.\n\nIf you prefer to count cache line basis, then I am counting it twice\nintentionally.\n\n>\n> In my micro-arch, the number of prefetch slots is based on cache line\n> miss so this would be overcounting by a factor of 2.\n\nI am not entirely sure if this will be useful for all the cores. It is\nshown to beneficial for falkor based on what is done in LLVM.\n\nThanks,\nKugan\n>\n> Thanks,\n> Andrew\n>\n>>\n>> Thanks,\n>> Kugan\n>>\n>> gcc/ChangeLog:\n>>\n>> 2017-09-12 Kugan Vivekanandarajah \n>>\n>> * cfgloop.h (iv_analyze_biv): export.\n>> * loop-iv.c: Likewise.\n>> * config/aarch64/aarch64.c (strided_load_p): New.\n>> (insn_has_strided_load): New.\n>> (count_strided_load_rtl): New.\n>> (aarch64_loop_unroll_adjust): New.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-462343-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"KO801Ide\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwQf12nntz9s7c\n\tfor ;\n\tMon, 18 Sep 2017 09:41:59 +1000 (AEST)","(qmail 88149 invoked by alias); 17 Sep 2017 23:41:50 -0000","(qmail 87073 invoked by uid 89); 17 Sep 2017 23:41:49 -0000","from mail-qk0-f171.google.com (HELO mail-qk0-f171.google.com)\n\t(209.85.220.171) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tSun, 17 Sep 2017 23:41:39 +0000","by mail-qk0-f171.google.com with SMTP id s132so5911401qke.7 for\n\t; Sun, 17 Sep 2017 16:41:39 -0700 (PDT)","by 10.237.37.211 with HTTP; Sun, 17 Sep 2017 16:41:37 -0700 (PDT)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; q=dns; s=default; b=HPDU/oEGVBovxgZ\n\tokX7ysaHDRf0CE+W18hWUVIcpjvuxW6u07CFT4pLTeGAu7f9fQ9J8SeMHkpwpXUS\n\tSZPcKKUWJPTAJ/VnkBtbLq1cQpMWELIEOR/vvYUPSB30PPq1h4y9D/i6XiolxSrK\n\t7jLSk7HcCuMJJcyvN8I9WGYW+uBA=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; s=default; bh=C2ZA0okbMjAnL7tXXnyID\n\tWT2Xs8=; b=KO801Ide95M9BXGEpRB5FEDRdcvCa3hstUOpsInJEz0mukRHCjEjq\n\tQ1PihnwUJtIldKuE1+5aWhCpMQWil08mJ+tl8m6aK5sMTyE/0FDfidkPZ56jnwVc\n\twec2NrtWBJkHCHQGZah2S4lwg3SWRH4BfDWR18Q1LeX71M+c8db+lQ=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.6 required=5.0 tests=AWL, BAYES_00,\n\tRCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=terminology,\n\tHx-languages-length:2636","X-HELO":"mail-qk0-f171.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;\n\ts=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=lVs3feg2VwRtXLEcod9dBR4vRqS0pYbx8Q2CduO066U=;\n\tb=jnQku20pnCZx1jtu5/3w7f4PYsUSHz+ulBC53qMRxnoeqQtDqwiPvEYPEOKO2DpQpG\n\tvgKjw1UIb+C/DY+3h51aSsM3zor6GkVK6vqzm6Eu/9KUG5InTcsoJ2Od3AbDlASaZ+gh\n\tRoOVFQg4BKvyVN+TqjNzPkdiIyRTUw41mFvweZOq1fnGXuwmvocjmtqDG1UwuAu2XwdP\n\tfz7Zvk8GnvkGUS/GmyKteTvKD0eSGeGdWHoEQh3emwPuaPWiRmnZ5cD9Vxyp7WlIt7nE\n\tl+M7Et82wvXj67ZZZbWlHVpmfDtgQsCvGJepi36MGd7apuGO6z2zzProSz5vqBugzCPP\n\tIchA==","X-Gm-Message-State":"AHPjjUjkZ+c5OvV3BOA6FJBPxMHLX+EGe8OmqfHiASHAQy/3wcDK5O6g\tbeXiQakDjlYNicXRlmefOCs9uSiRVF+cDXSRMXoGKw==","X-Google-Smtp-Source":"AOwi7QDqX2WXXoeHvASR1B4Tce60I/RIZsVdTggl4FYeKuxgY1dQtcgUIps54/Uv8lCDEcgBUXZ0DDkSM7nJlvq/+fc=","X-Received":"by 10.55.170.216 with SMTP id\n\tt207mr16713180qke.232.1505691697846;\n\tSun, 17 Sep 2017 16:41:37 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"\n\t","From":"Kugan Vivekanandarajah ","Date":"Mon, 18 Sep 2017 09:41:37 +1000","Message-ID":"","Subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","To":"Andrew Pinski ","Cc":"\"gcc-patches@gcc.gnu.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","X-IsSubscribed":"yes"}},{"id":1769824,"web_url":"http://patchwork.ozlabs.org/comment/1769824/","msgid":"","list_archive_url":null,"date":"2017-09-17T23:52:29","subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","submitter":{"id":40,"url":"http://patchwork.ozlabs.org/api/people/40/","name":"Andrew Pinski","email":"pinskia@gmail.com"},"content":"On Sun, Sep 17, 2017 at 4:41 PM, Kugan Vivekanandarajah\n wrote:\n> Hi Andrew,\n>\n> On 15 September 2017 at 13:36, Andrew Pinski wrote:\n>> On Thu, Sep 14, 2017 at 6:33 PM, Kugan Vivekanandarajah\n>> wrote:\n>>> This patch adds aarch64_loop_unroll_adjust to limit partial unrolling\n>>> in rtl based on strided-loads in loop.\n>>\n>> Can you expand on this some more? Like give an example of where this\n>> helps? I am trying to better understand your counting schemes since\n>> it seems like the count is based on the number of loads and not cache\n>> lines.\n>\n> This is a simplified model and I am assuming here that prefetcher will\n> tune based on the memory accesses. I don't have access to any of the\n> internals of how this is implemented in different microarchitectures\n> but I am assuming (in a simplified sense) that hw logic will detect\n> memory accesses patterns and using this it will prefetch the cache\n> line. If there are memory accesses like what you have shown that falls\n> within the cache line, they may be combined but you still need to\n> detect them and tune. And also detecting them at compile time is not\n> always easy. So this is a simplified model.\n>\n>> What do you mean by a strided load?\n>> Doesn't this function overcount when you have:\n>> for(int i = 1;i<1024;i++)\n>> {\n>> t+= a[i-1]*a[i];\n>> }\n>> if it is counting based on cache lines rather than based on load addresses?\n> Sorry for my terminology. what I mean by strided access is any memory\n> accesses in the form memory[iv]. I am counting memory[iv] and\n> memory[iv+1] as two deferent streams. This may or may not fall into\n> same cache line.\n>\n>>\n>> It also seems to do some weird counting when you have:\n>> for(int i = 1;i<1024;i++)\n>> {\n>> t+= a[(i-1)*N+i]*a[(i)*N+i];\n>> }\n>>\n>> That is:\n>> (PLUS (REG) (REG))\n>>\n>> Also seems to overcount when loading from the same pointer twice.\n>\n> If you prefer to count cache line basis, then I am counting it twice\n> intentionally.\n>\n>>\n>> In my micro-arch, the number of prefetch slots is based on cache line\n>> miss so this would be overcounting by a factor of 2.\n>\n> I am not entirely sure if this will be useful for all the cores. It is\n> shown to beneficial for falkor based on what is done in LLVM.\n\nCan you share at least one benchmark or microbenchmark which shows the\nbenefit? Because I can't seem to understand how the falkor core\nhandles their hardware prefetcher to see if this is beneficial even\nthere?\n\nThanks,\nAndrew\n\n>\n> Thanks,\n> Kugan\n>>\n>> Thanks,\n>> Andrew\n>>\n>>>\n>>> Thanks,\n>>> Kugan\n>>>\n>>> gcc/ChangeLog:\n>>>\n>>> 2017-09-12 Kugan Vivekanandarajah \n>>>\n>>> * cfgloop.h (iv_analyze_biv): export.\n>>> * loop-iv.c: Likewise.\n>>> * config/aarch64/aarch64.c (strided_load_p): New.\n>>> (insn_has_strided_load): New.\n>>> (count_strided_load_rtl): New.\n>>> (aarch64_loop_unroll_adjust): New.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-462344-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"oEM9NKLi\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwQtW5T2kz9s7M\n\tfor ;\n\tMon, 18 Sep 2017 09:52:49 +1000 (AEST)","(qmail 99401 invoked by alias); 17 Sep 2017 23:52:42 -0000","(qmail 99392 invoked by uid 89); 17 Sep 2017 23:52:41 -0000","from mail-io0-f172.google.com (HELO mail-io0-f172.google.com)\n\t(209.85.223.172) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tSun, 17 Sep 2017 23:52:31 +0000","by mail-io0-f172.google.com with SMTP id d16so14942462ioj.3 for\n\t; Sun, 17 Sep 2017 16:52:31 -0700 (PDT)","by 10.157.27.244 with HTTP; Sun, 17 Sep 2017 16:52:29 -0700 (PDT)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; q=dns; s=default; b=WmcS8keVWfKMPv6\n\t3cD4rFmnrmiMQk3jyqW/sEG+q4apP0oykkj67RvFquwYfiUNLa4f17axlv5kDBO+\n\tmZ7yBCmcvzEfexJerSMQPucSIvupd2/CC0L53vlOmSQemGBRR4KxpNFf5c7+QY0Q\n\tSau4u35mJdKkxZJsigqCHFy+cDKc=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:mime-version:in-reply-to:references:from:date:message-id\n\t:subject:to:cc:content-type; s=default; bh=1kI22l0j3ZIXn/wC9CvVB\n\t9bm/lo=; b=oEM9NKLiJaBHJV/TdsvfGvcd6mihmyTCnAU4PdcWzCWIMSjkBbRju\n\tayhxgxXnQKVhH9o8bTfsaKHrveQIzqnouCAECDtoTKGdMVQYjZJASjrXJiRh7FGv\n\ttV/h+G7gEgepF8/flpWxmi2uKUSD9vMwr/xwtrb5MTO6Efs0BhsWm4=","Mailing-List":"contact gcc-patches-help@gcc.gnu.org; run by ezmlm","Precedence":"bulk","List-Id":"","List-Unsubscribe":"","List-Archive":"","List-Post":"","List-Help":"","Sender":"gcc-patches-owner@gcc.gnu.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.7 required=5.0 tests=AWL, BAYES_00,\n\tFREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=terminology","X-HELO":"mail-io0-f172.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;\n\ts=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=zj1WbWS3RytUzsl1VN80gQvgcBLqiNYP9l1aB7QDQxc=;\n\tb=m2RVd2gNy05VwOzHSq5IODgbTq076ED4gjYNTd8eiDNWEHyw0aNHECLDySs0ggXURj\n\tX95IYhz6bH46hi2hx6rMdcyiQEFQ7sEebtp9Xeq9BGPN0pdBcplBWj7NYA3+BeahE3zP\n\t3ljdxz3aimoR0TmomuKubsJhpumiXGBe2FGy0+r1C2JYTszbQQSszT8DdZ+jyq84MhpB\n\tDR8RmKLNH1SkcyzMyYxHbNZihtzi2TLBMSctzA1A0ruaIdlHHHzq8ALOOKNxkgrx/VXG\n\ty324b34wWnD7jMpjh2C8K6vOU2bE6f8oskFUjA3pVYN4gtV85Z3m66XyKKrH4uA0i/45\n\t4SrA==","X-Gm-Message-State":"AHPjjUjxXgJxhyfU9Y8te8rhvHcNhdQZGjwwCvgjiYpAmTg/znIQutXw\tZXraFe7U17SXqdK/hIASJIYK1bBwzd19tDoLxgc=","X-Google-Smtp-Source":"AOwi7QC1lTS4nHUlM37ZvJgQ8yYtLZA3Fv/5u9GQjDQL4UwbWpHNuinrUq/kGVSyll6hzKoxFLLK/IytLTLkxwv2u8U=","X-Received":"by 10.202.58.131 with SMTP id\n\th125mr14644653oia.203.1505692349893;\n\tSun, 17 Sep 2017 16:52:29 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"\n\t\n\t","From":"Andrew Pinski ","Date":"Sun, 17 Sep 2017 16:52:29 -0700","Message-ID":"","Subject":"Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to\n\tlimit partial unrolling in rtl based on strided-loads in loop","To":"Kugan Vivekanandarajah ","Cc":"\"gcc-patches@gcc.gnu.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","X-IsSubscribed":"yes"}}]