Re: [PATCH 22/23] Add rtl-ssa
On 12/16/20 5:33 PM, Richard Sandiford wrote: > Jeff Law via Gcc-patches writes: >> On 11/13/20 1:23 AM, Richard Sandiford via Gcc-patches wrote: >>> This patch adds the RTL SSA infrastructure itself. The following >>> fwprop.c patch will make use of it. >>> >>> gcc/ >>> * configure.ac: Add rtl-ssa to the list of dependence directories. >>> * configure: Regenerate. >>> * Makefile.in (rtl-ssa-warn): New variable. >>> (OBJS): Add the rtl-ssa object files. >>> * emit-rtl.h (rtl_data::ssa): New field. >>> * rtl-ssa.h: New file. >>> * system.h: Include when INCLUDE_FUNCTIONAL is defined. >>> * rtl-ssa: New directory. >> So I know its late in stage3, but I think the risks here are relatively >> minor as this would only be used in fwprop right now and it was posted >> in advance of the deadline. >> >> My high level questions/concerns have been addressed and while I >> strongly suspect we'll have to iterate on infrastructure, I think we can >> do that on demand as passes start to use the infrastructure and we have >> a clearer picture of what tweaks we need to make for the clients. > Agreed. And I agree we'll need to iterate. What's there now certainly > isn't complete. > >> Obviously we'll want to keep an eye on testresults, but again, the >> potential for fallout here is relatively minor IMHO. OK for the trunk. > Thanks a lot for the reviews. Now pushed after retesting on > aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf > (as far as I could given the current state), x86_64-linux-gnu > and powerpc64le-linux-gnu. And most of the older embedded targets look OK as well. There's one or two regressions that I haven't bisected yet, but nothing at this point that screams out that things are broken badly. jeff
Re: [PATCH 22/23] Add rtl-ssa
Jeff Law via Gcc-patches writes: > On 11/13/20 1:23 AM, Richard Sandiford via Gcc-patches wrote: >> This patch adds the RTL SSA infrastructure itself. The following >> fwprop.c patch will make use of it. >> >> gcc/ >> * configure.ac: Add rtl-ssa to the list of dependence directories. >> * configure: Regenerate. >> * Makefile.in (rtl-ssa-warn): New variable. >> (OBJS): Add the rtl-ssa object files. >> * emit-rtl.h (rtl_data::ssa): New field. >> * rtl-ssa.h: New file. >> * system.h: Include when INCLUDE_FUNCTIONAL is defined. >> * rtl-ssa: New directory. > So I know its late in stage3, but I think the risks here are relatively > minor as this would only be used in fwprop right now and it was posted > in advance of the deadline. > > My high level questions/concerns have been addressed and while I > strongly suspect we'll have to iterate on infrastructure, I think we can > do that on demand as passes start to use the infrastructure and we have > a clearer picture of what tweaks we need to make for the clients. Agreed. And I agree we'll need to iterate. What's there now certainly isn't complete. > Obviously we'll want to keep an eye on testresults, but again, the > potential for fallout here is relatively minor IMHO. OK for the trunk. Thanks a lot for the reviews. Now pushed after retesting on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf (as far as I could given the current state), x86_64-linux-gnu and powerpc64le-linux-gnu. Richard
Re: [PATCH 22/23] Add rtl-ssa
On 11/13/20 1:23 AM, Richard Sandiford via Gcc-patches wrote: > This patch adds the RTL SSA infrastructure itself. The following > fwprop.c patch will make use of it. > > gcc/ > * configure.ac: Add rtl-ssa to the list of dependence directories. > * configure: Regenerate. > * Makefile.in (rtl-ssa-warn): New variable. > (OBJS): Add the rtl-ssa object files. > * emit-rtl.h (rtl_data::ssa): New field. > * rtl-ssa.h: New file. > * system.h: Include when INCLUDE_FUNCTIONAL is defined. > * rtl-ssa: New directory. So I know its late in stage3, but I think the risks here are relatively minor as this would only be used in fwprop right now and it was posted in advance of the deadline. My high level questions/concerns have been addressed and while I strongly suspect we'll have to iterate on infrastructure, I think we can do that on demand as passes start to use the infrastructure and we have a clearer picture of what tweaks we need to make for the clients. Obviously we'll want to keep an eye on testresults, but again, the potential for fallout here is relatively minor IMHO. OK for the trunk. Jeff
