On 12/16/20 5:33 PM, Richard Sandiford wrote:
> Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> 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 <functional> 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
