This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH V4] Loop split upon semi-invariant condition (PR tree-optimization/89134)
- From: Feng Xue OS <fxue at os dot amperecomputing dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Michael Matz <matz at suse dot de>, Philipp Tomsich <philipp dot tomsich at theobroma-systems dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Christoph Müllner <christoph dot muellner at theobroma-systems dot com>, "erick dot ochoa at theobroma-systems dot com" <erick dot ochoa at theobroma-systems dot com>
- Date: Wed, 6 Nov 2019 07:13:18 +0000
- Subject: Re: [PATCH V4] Loop split upon semi-invariant condition (PR tree-optimization/89134)
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zz+P0jzx1WJMYQ4q5kre6i571tSsNLYR/5thNId9/lQ=; b=Voonxj6tw2eXWaZuc3CHmKRYW9YeCTOEKyTcRcQ6CefoNoNxFYBNaEDD3sBeN75IyAKackWOac4YI8IGeRFtz/dXvg3S0ZtDicmtnioq6P9tQLVUiiEKcJsCSCDaXxiao8lm66VBqsQ/cWjg0V2RF74T/Dj32DbKn4/uWUpyR4K3S+y5U7s5k/UxuECuffMfHE+6xURI3o4WKh8g1U3PIf7sU0sLnNzCNXyFFvfPqkpi99u+XhNQpMqdok7j6h+YeVztjHMIvZHScA1w0zfMjHbw179s6lKMe4pi8Vy2jl6qDnNOkLYaCjFh1mG+dcdK7NcWbcWeSfEVyNDcRqrCRg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ndUKuwYnysxud7YmaNpX0WmG/GPBqhfdHv1rmTSzZ0u2rvNroT+wEZlLG65DYfhyCVHEuipG5csBKA4Kk5nMXBoC3i6zI5SUebh/59h8mtiMHgah6AJANXBOtMLmk921JfSAMLWiCKGzBT4M6IZsMjULJ3c+2NWReqVL+JQCRDR6KZ9QEJKj6aHToAEAhWgCoC3r8ir/SEM83VEn2rWsI7Mv2vBHqqoUvBKibrO0CKU86f1Gda8aW0aIj6walot/WebVxBRqvJdHrjm1/a+SLz5q693wVxCD5O+IYAL9bABOO8h0wIMYwB3CiqI1PHYOxT/x8lj8Rp8KtQ7904yW9Q==
- References: <BYAPR01MB486993CD64F7326C9029BFBFF7490@BYAPR01MB4869.prod.exchangelabs.com> <CAFiYyc0+=1TDgkO0BQN_hdTBo=Nf+h_xF5SB6O8VM5s_cppQdg@mail.gmail.com> <BYAPR01MB4869641E6E9DCB49618D27B0F7300@BYAPR01MB4869.prod.exchangelabs.com> <CAFiYyc1tYTkUkziKYY6r=k8XFe5Er=oNkxW-cerbP7oq06c=wA@mail.gmail.com> <BYAPR01MB48697F52CD6FF3DFE2F78211F7EA0@BYAPR01MB4869.prod.exchangelabs.com> <BYAPR01MB4869403E98A1528A9219419CF7CF0@BYAPR01MB4869.prod.exchangelabs.com> <alpine.LSU.2.21.1907291743000.25869@wotan.suse.de> <BYAPR01MB48696037867D1A1D63825956F7B00@BYAPR01MB4869.prod.exchangelabs.com> <BYAPR01MB4869701BB6BAB25FEFCB8384F7B00@BYAPR01MB4869.prod.exchangelabs.com> <570EF6F3-6A76-4550-B8AB-0BD2486F3C3E@theobroma-systems.com> <alpine.LSU.2.21.1910151601020.5395@wotan.suse.de> <BYAPR01MB48695BBB22F6E142372B0B2FF7680@BYAPR01MB4869.prod.exchangelabs.com> <alpine.LSU.2.21.1910221105470.30048@wotan.suse.de> <BYAPR01MB48699D8CC5C995D6EC90BCACF76B0@BYAPR01MB4869.prod.exchangelabs.com> <CAFiYyc2sNo=5-K4VTks6MD8625tALHQDoQDf-nHMprMzk3ehWg@mail.gmail.com> <BYAPR01MB486986B62B74E6B008345F2EF76B0@BYAPR01MB4869.prod.exchangelabs.com> <CAFiYyc0ioy5_=i_g3+mXWnDv19dyyB5TDdM5AmE7bS_FX=hwFQ@mail.gmail.com> <BYAPR01MB4869DBC5913DE87313A1C53BF7650@BYAPR01MB4869.prod.exchangelabs.com> <BYAPR01MB4869DEE982BF85E8B487C313F7630@BYAPR01MB4869.prod.exchangelabs.com>,<CAFiYyc2STJ47QVTDQrLngCV3iHWe16pyCZN6PoO1xyEzam7dWA@mail.gmail.com>
> Uh. Note it's not exactly helpful to change algorithms between
> reviews, that makes it
> just harder :/
>
> Btw, I notice you use post-dominance info. Note that we generally do
> not keep that
> up-to-date with CFG manipulations (and for dominators fast queries are
> disabled).
> Probably the way we walk & transform loops makes this safe but it's something to
> remember when extending that. Possibly doing analysis of all candidates first
> and then applying the transform for all wanted cases would avoid this (and maybe
> also can reduce the number of update_ssa calls). I guess this can be done as
> followup.
Ok. Thanks for the suggestion.
Feng