[{"id":1768934,"web_url":"http://patchwork.ozlabs.org/comment/1768934/","msgid":"","list_archive_url":null,"date":"2017-09-15T03:44:38","subject":"Re: [RFC][PACH 3/5] Prevent tree unroller from completely unrolling\n\tinner loops if that results in excessive strided-loads in outer 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:30 PM, Kugan Vivekanandarajah\n wrote:\n> This patch prevent tree unroller from completely unrolling inner loops if that\n> results in excessive strided-loads in outer loop.\n\nSame comments from the RTL version.\n\nThough one more comment here:\n+ if (!INDIRECT_REF_P (op)\n+ && TREE_CODE (op) != MEM_REF\n+ && TREE_CODE (op) != TARGET_MEM_REF)\n+ continue;\n\nThis does not handle ARRAY_REF which might be/should be handled.\n\n\n+ if ((loop_father = loop_outer (loop)))\n\nSince you don't use loop_father outside of the if statement use the\nfollowing (allowed) format\nif (struct loop *loop_father = loop_outer (loop))\n\nThinking about this more, hw_prefetchers_avail might not be equivalent\nto num_slots (PARAM_SIMULTANEOUS_PREFETCHES) but the name does not fit\nwhat it means if I understand your hardware correctly.\nMaybe hw_load_non_cacheline_prefetcher_avail since if I understand the\nmicro-arch is that the prefetchers are not based on the cacheline\nbeing loaded.\n\nThanks,\nAndrew\n\n>\n> Thanks,\n> Kugan\n>\n> gcc/ChangeLog:\n>\n> 2017-09-12 Kugan Vivekanandarajah \n>\n> * config/aarch64/aarch64.c (count_mem_load_streams): New.\n> (aarch64_ok_to_unroll): New.\n> * doc/tm.texi (ok_to_unroll): Define new target hook.\n> * doc/tm.texi.in (ok_to_unroll): Likewise.\n> * target.def (ok_to_unroll): Likewise.\n> * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Use\n> ok_to_unroll while unrolling.","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-462196-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=\"AFKRevpD\"; 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 3xth9b4sxRz9t2f\n\tfor ;\n\tFri, 15 Sep 2017 13:44:49 +1000 (AEST)","(qmail 10592 invoked by alias); 15 Sep 2017 03:44:42 -0000","(qmail 10580 invoked by uid 89); 15 Sep 2017 03:44:41 -0000","from mail-io0-f177.google.com (HELO mail-io0-f177.google.com)\n\t(209.85.223.177) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tFri, 15 Sep 2017 03:44:40 +0000","by mail-io0-f177.google.com with SMTP id e189so5483492ioa.4 for\n\t; Thu, 14 Sep 2017 20:44:40 -0700 (PDT)","by 10.157.27.244 with HTTP; Thu, 14 Sep 2017 20:44:38 -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=eNv4j0DdN7HQ/tp\n\txNBbORmVx0P3i8Xvlj6MpLW+KvK3MvKcj8klczAB5lvaHe+0ppfshhaAOMmhH/+Z\n\tHMwtgPESowrwx9CfXJnsvjQAIBSJqjx3R8yJ/jtFPDZNKOPvUsL70arpJoUTYjl1\n\tmr7GOvTQhG6RjFt9pTW0ePQo+Oew=","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=f5ytfieZx7A/ZHkAONVVn\n\tSPf1ZI=; b=AFKRevpDSUy0qv43mDPSmOkP3uLu+5oP44tugPJ5sggWKq/G0Ttlh\n\t8+3uEw4odm3JHYWdT3HBymnOp/2XoshF83rCzACa8WPQh7j4CRTue1htHjFtESg8\n\tMoykYfybovOzoIOVCO+T7jQf9VmfD+0hhZRFY45sjPaqvhOoTU9aGM=","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=","X-HELO":"mail-io0-f177.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=g+RXg0I/E3RvTzoZ8EvB8PpyxzQ0ILKO8o9F+BBDsF4=;\n\tb=G/SCcYrzDBLrOTAe3OfSC4v5A6GFiVwmn6gHK/DUG5jCSN59y+LuKWzFglq4707K0A\n\tqyHTobnK/C6tG4N45zRIsGqTZW/UXanGcPm62mAKwN/oqP6j3bSVkVVaSCvkDsBCJvbJ\n\tIMQasndJebdLK2tlIPC3y/jv+lgWBLkcqSxCbC0N4f/PluX86f4Km1UAOAHFl3fxM0si\n\tmG5EjuHRco1tiC1OgByMDOfnFM3CG3nM93+VqPhZIz/lucOmGv7IG6WUgZnbgVX66azx\n\tr6MqIBdx5CfzCkapL6VwRYP+HNQWDHCc1CeY23cGU+Yi3m73qkaajFTPexvs6YfYeo3a\n\t+eMg==","X-Gm-Message-State":"AHPjjUjSnkNSwgMHh1payccnSG1G0ApZFBgLcrf9/85HcJN1SKjyd72E\tcRl3NDqhkVQNLSVyMLWq12l/OF7lETyUYT9QIKM=","X-Google-Smtp-Source":"AOwi7QBaPEixymEQFO/MOu0JWyVpwKtuaBunHvU5PhO/p0+Y9vOyc3KB/aqga0/7w3Yxuf07aMdD3HG9tgKdM5y01Q8=","X-Received":"by 10.202.12.66 with SMTP id i2mr25483167oiy.314.1505447078530;\n\tThu, 14 Sep 2017 20:44:38 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"","From":"Andrew Pinski ","Date":"Thu, 14 Sep 2017 20:44:38 -0700","Message-ID":"","Subject":"Re: [RFC][PACH 3/5] Prevent tree unroller from completely unrolling\n\tinner loops if that results in excessive strided-loads in outer loop","To":"Kugan Vivekanandarajah ","Cc":"\"gcc-patches@gcc.gnu.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","X-IsSubscribed":"yes"}},{"id":1769085,"web_url":"http://patchwork.ozlabs.org/comment/1769085/","msgid":"","list_archive_url":null,"date":"2017-09-15T09:42:34","subject":"Re: [RFC][PACH 3/5] Prevent tree unroller from completely unrolling\n\tinner loops if that results in excessive strided-loads in outer loop","submitter":{"id":1765,"url":"http://patchwork.ozlabs.org/api/people/1765/","name":"Richard Biener","email":"richard.guenther@gmail.com"},"content":"On Fri, Sep 15, 2017 at 5:44 AM, Andrew Pinski wrote:\n> On Thu, Sep 14, 2017 at 6:30 PM, Kugan Vivekanandarajah\n> wrote:\n>> This patch prevent tree unroller from completely unrolling inner loops if that\n>> results in excessive strided-loads in outer loop.\n>\n> Same comments from the RTL version.\n>\n> Though one more comment here:\n> + if (!INDIRECT_REF_P (op)\n\nThere's no INDIRECT_REF in GIMPLE.\n\n> + && TREE_CODE (op) != MEM_REF\n> + && TREE_CODE (op) != TARGET_MEM_REF)\n> + continue;\n>\n> This does not handle ARRAY_REF which might be/should be handled.\n\nIt looks like he wants to do\n\n op = get_base_address (op);\n\nfirst.\n\nBut OTOH the routine looks completely bogus to me ...\n\nYou want to do\n\n find_data_references_in_stmt ()\n\nand then look at the data-refs and the evolution of their access fns.\n\nThe function needs _way_ more comments though, you have to apply excessive\nguessing as to what it computes. It also feels like this should be a target\nhook but part of some generic cost modeling infrastructure and the target\nshould instead provide the number of load/store streams it can handle\nwell (aka HW-prefetch). That would be also (very) useful information\nfor the loop distribution pass.\n\nRelated information that is missing is for the vectorizer peeling cost model\nthe number of store buffers when deciding whether to peel stores for alignment\nfor example.\n\nRichard.\n\n>\n> + if ((loop_father = loop_outer (loop)))\n>\n> Since you don't use loop_father outside of the if statement use the\n> following (allowed) format\n> if (struct loop *loop_father = loop_outer (loop))\n>\n> Thinking about this more, hw_prefetchers_avail might not be equivalent\n> to num_slots (PARAM_SIMULTANEOUS_PREFETCHES) but the name does not fit\n> what it means if I understand your hardware correctly.\n> Maybe hw_load_non_cacheline_prefetcher_avail since if I understand the\n> micro-arch is that the prefetchers are not based on the cacheline\n> being loaded.\n>\n> Thanks,\n> Andrew\n>\n>>\n>> Thanks,\n>> Kugan\n>>\n>> gcc/ChangeLog:\n>>\n>> 2017-09-12 Kugan Vivekanandarajah \n>>\n>> * config/aarch64/aarch64.c (count_mem_load_streams): New.\n>> (aarch64_ok_to_unroll): New.\n>> * doc/tm.texi (ok_to_unroll): Define new target hook.\n>> * doc/tm.texi.in (ok_to_unroll): Likewise.\n>> * target.def (ok_to_unroll): Likewise.\n>> * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Use\n>> ok_to_unroll while unrolling.","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-462212-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=\"hLrDeR5E\"; 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 3xtr6f09G5z9s7c\n\tfor ;\n\tFri, 15 Sep 2017 19:42:49 +1000 (AEST)","(qmail 80249 invoked by alias); 15 Sep 2017 09:42:39 -0000","(qmail 80233 invoked by uid 89); 15 Sep 2017 09:42:38 -0000","from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com)\n\t(74.125.82.67) by sourceware.org\n\t(qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tFri, 15 Sep 2017 09:42:37 +0000","by mail-wm0-f67.google.com with SMTP id r136so2274522wmf.3 for\n\t; Fri, 15 Sep 2017 02:42:36 -0700 (PDT)","by 10.80.180.250 with HTTP; Fri, 15 Sep 2017 02:42:34 -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=f63zWRW0GijjBPy\n\t4je6zG58dY8nPSONrpd57G8avJ9XHQF1P4IfDQ755DQ+HFV/ixtlXsvoF/SPs5Ll\n\t+xGDTsFyxke5dIVi+TYr0oNcibmwBY1mL7D2jLQfgKh2dKy51dWCleZPl6R4pYDI\n\tHPl354rEaB5YG5PXfAK00+o+bq2g=","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=GfP1tbP05M9Wc78vAya+j\n\ti6YD3I=; b=hLrDeR5EM2mKxsCJitHUdTy7VUI8USB9egOLeij4LSywla01yCDc+\n\tg2GzgGbEUPl9bQNZTp2Im7M2kyXD1hUk3rZEhUDGLHu0Nt/ro672hb7I9ujhye1t\n\tZDjIBqX7UNW/Be5uO3m8Z3uc0PJeoenAeBgrju4mwxtrETMMvKYcRo=","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\n\tspammy=Hx-spam-relays-external:74.125.82.67, H*RU:74.125.82.67","X-HELO":"mail-wm0-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=a4toRvd7eJK5DbqTiS9qhsFzom/xUwmWCi00ZV/w81I=;\n\tb=Bxj/U4vnxEwSYD32/vhG5Ju9ZCFlZn5PoU85KgFBIu95CBXshn2waVJkiGGyaLqbn9\n\tVCM/uZHqsYpYJ9F1d1NovC2Fk3REvZEOSnv4h8wooPBMxK0EB4Wk03jx+PPD6oMo1kPK\n\tXOxSRRGHGzJP7mitaoLslT0d0U3mZKMyTtlaEjSq4OQnAVsK8ftBIFkFrQOXpZj3yqFM\n\tO6URV4Pt1XfVroa+fs6mrqiXJpozBwlle/91vvZzA70cTqUmDENDI6IPsVNcoZreeOfo\n\tKTWhnFVS4RpxsEs0LeGMOClbG89dkSqbob2KO+X19G+7gQkIIJvFsWz6GefD79nnLqaK\n\t6Hbw==","X-Gm-Message-State":"AHPjjUhQaTAu5rUlex3PIq6YrQmNMWdl4kHHDCDV/as+pniQe0uTUTyU\trTikTtweWPIslOYO9HF/oS8itTYTGk1+qfBWZDo=","X-Google-Smtp-Source":"AOwi7QC+z6qgEwcXQW0ahpU4k+3FbyBQJlbUubfNgbV2GD+2qxF6/1whsc+pg+DGfyvhdLoyrrQAKwjElkRSMSZt3M4=","X-Received":"by 10.80.175.228 with SMTP id h91mr9208056edd.292.1505468555175;\n\tFri, 15 Sep 2017 02:42:35 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"\n\t","From":"Richard Biener ","Date":"Fri, 15 Sep 2017 11:42:34 +0200","Message-ID":"","Subject":"Re: [RFC][PACH 3/5] Prevent tree unroller from completely unrolling\n\tinner loops if that results in excessive strided-loads in outer loop","To":"Andrew Pinski ","Cc":"Kugan Vivekanandarajah ,\n\t\"gcc-patches@gcc.gnu.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","X-IsSubscribed":"yes"}},{"id":1769253,"web_url":"http://patchwork.ozlabs.org/comment/1769253/","msgid":"<5a28e9ba-2de3-babc-0e3c-6c25341d3dfe@redhat.com>","list_archive_url":null,"date":"2017-09-15T15:26:55","subject":"Re: [RFC][PACH 3/5] Prevent tree unroller from completely unrolling\n\tinner loops if that results in excessive strided-loads in outer loop","submitter":{"id":4400,"url":"http://patchwork.ozlabs.org/api/people/4400/","name":"Jeff Law","email":"law@redhat.com"},"content":"On 09/15/2017 03:42 AM, Richard Biener wrote:\n> On Fri, Sep 15, 2017 at 5:44 AM, Andrew Pinski wrote:\n>> On Thu, Sep 14, 2017 at 6:30 PM, Kugan Vivekanandarajah\n>> wrote:\n>>> This patch prevent tree unroller from completely unrolling inner loops if that\n>>> results in excessive strided-loads in outer loop.\n>>\n>> Same comments from the RTL version.\n>>\n>> Though one more comment here:\n>> + if (!INDIRECT_REF_P (op)\n> \n> There's no INDIRECT_REF in GIMPLE.\n> \n>> + && TREE_CODE (op) != MEM_REF\n>> + && TREE_CODE (op) != TARGET_MEM_REF)\n>> + continue;\n>>\n>> This does not handle ARRAY_REF which might be/should be handled.\n> \n> It looks like he wants to do\n> \n> op = get_base_address (op);\n> \n> first.\n> \n> But OTOH the routine looks completely bogus to me ...\n> \n> You want to do\n> \n> find_data_references_in_stmt ()\n> \n> and then look at the data-refs and the evolution of their access fns.\n> \n> The function needs _way_ more comments though, you have to apply excessive\n> guessing as to what it computes. It also feels like this should be a target\n> hook but part of some generic cost modeling infrastructure and the target\n> should instead provide the number of load/store streams it can handle\n> well (aka HW-prefetch). That would be also (very) useful information\n> for the loop distribution pass.\n> \n> Related information that is missing is for the vectorizer peeling cost model\n> the number of store buffers when deciding whether to peel stores for alignment\n> for example.\nYea. I'd much rather see a costing model of some kind rather than just\ncalling into a backend hook to disable the transformation in some cases.\n\nJeff","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-462255-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=\"uPy30cRw\"; dkim-atps=neutral","sourceware.org; auth=none","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=law@redhat.com"],"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 3xtzly08VWz9sPr\n\tfor ;\n\tSat, 16 Sep 2017 01:27:08 +1000 (AEST)","(qmail 93767 invoked by alias); 15 Sep 2017 15:27:01 -0000","(qmail 93585 invoked by uid 89); 15 Sep 2017 15:27:01 -0000","from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by\n\tsourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tFri, 15 Sep 2017 15:27:00 +0000","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com\n\t[10.5.11.16])\t(using TLSv1.2 with cipher AECDH-AES256-SHA\n\t(256/256 bits))\t(No client certificate requested)\tby\n\tmx1.redhat.com (Postfix) with ESMTPS id D990A821C7;\n\tFri, 15 Sep 2017 15:26:57 +0000 (UTC)","from localhost.localdomain (ovpn-112-55.rdu2.redhat.com\n\t[10.10.112.55])\tby smtp.corp.redhat.com (Postfix) with ESMTP\n\tid 8AD8A71CB7; Fri, 15 Sep 2017 15:26:56 +0000 (UTC)"],"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:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; q=dns; s=\n\tdefault; b=MrVF7HhjjY+wsaJa/hpPF6KwyiGaP4PdafCmbbS+wNZy14BsHWVpu\n\tzr4Z+vm53ZDeaVbq53ElXkNYXKB8csC/JCe1yGuW8GG48t7rM1uPuGnLcutgnuwK\n\tzCb/EzY4fJyRHluCf97dJY7RtSaOHWeM4q0hz4eM1gVXJtp9ySkSGA=","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:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; s=default;\n\tbh=fkhq445cj16huE1dUsj0eLgSDDs=; b=uPy30cRwveKjSWFieB4InU4s7V49\n\t3PDa9cs3OxHTh+oCvcXRBB3R60d+qGTM/xWYS9jAhMWaRa8n3AynAjTGZ02QcPLj\n\tToZGuWy1QRYbI/J+xiwCHJ3n510WVnOXTmfNznX7ka7JuGc3GFr0rr4KEFt/Xd5Z\n\tvILBrsmiwIJOTJM=","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.9 required=5.0 tests=BAYES_00,\n\tRP_MATCHES_RCVD,\n\tSPF_HELO_PASS autolearn=ham version=3.3.2 spammy=","X-HELO":"mx1.redhat.com","DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com D990A821C7","Subject":"Re: [RFC][PACH 3/5] Prevent tree unroller from completely unrolling\n\tinner loops if that results in excessive strided-loads in outer loop","To":"Richard Biener ,\n\tAndrew Pinski ","Cc":"Kugan Vivekanandarajah ,\n\t\"gcc-patches@gcc.gnu.org\" ","References":"\n\t\n\t","From":"Jeff Law ","Message-ID":"<5a28e9ba-2de3-babc-0e3c-6c25341d3dfe@redhat.com>","Date":"Fri, 15 Sep 2017 09:26:55 -0600","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:52.0) Gecko/20100101 Thunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"7bit","X-IsSubscribed":"yes"}}]