[19/23] rtlanal: Add some new helper classes

[Jeff Law]

On 12/14/20 9:37 AM, Richard Sandiford wrote:
> Jeff Law <law@redhat.com> writes:
>> On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote:
>>> This patch adds some classes for gathering the list of registers
>>> and memory that are read and written by an instruction, along
>>> with various properties about the accesses.  In some ways it's
>>> similar to the information that DF collects for registers,
>>> but extended to memory.  The main reason for using it instead
>>> of DF is that it can analyse tentative changes to instructions
>>> before they've been committed.
>>>
>>> The classes also collect general information about the instruction,
>>> since it's cheap to do and helps to avoid multiple walks of the same
>>> RTL pattern.
>>>
>>> I've tried to optimise the code quite a bit, since with later patches
>>> it becomes relatively performance-sensitive.  See the discussion in
>>> the comments for the trade-offs involved.
>>>
>>> I put the declarations in a new rtlanal.h header file since it
>>> seemed a bit excessive to put so much new inline stuff in rtl.h.
>>>
>>> gcc/
>>> 	* rtlanal.h: New file.
>>> 	(MEM_REGNO): New constant.
>>> 	(rtx_obj_flags): New namespace.
>>> 	(rtx_obj_reference, rtx_properties): New classes.
>>> 	(growing_rtx_properties, vec_rtx_properties_base): Likewise.
>>> 	(vec_rtx_properties): New alias.
>>> 	* rtlanal.c: Include it.
>>> 	(rtx_properties::try_to_add_reg): New function.
>>> 	(rtx_properties::try_to_add_dest): Likewise.
>>> 	(rtx_properties::try_to_add_src): Likewise.
>>> 	(rtx_properties::try_to_add_pattern): Likewise.
>>> 	(rtx_properties::try_to_add_insn): Likewise.
>>> 	(vec_rtx_properties_base::grow): Likewise.
>> One might argue at least some of these should become first class
>> properties of insns but then we have the joy of keeping them up-to-date
>> as transformations are made.  It also reminds me a bit of the old
>> var_ann stuff we had in the tree SSA implementation. 
> Yeah.  The RTL SSA insn info does store these properties, but that has
> the advantage of being new code and so can require all updates to go
> through new interfaces.  I agree that ideally we'd store the information
> directly in RTL insns instead.
I guess it's less problematic since we're using real classes.  The old
annotation stuff was done before we had C++ & classes.

>
> I guess one question is where we would store the new flags.  In some
> ways it might be easier to do that after any future split of rtx_insn
> and rtx, since we could then use a smaller code field and potentially
> replace the mode field.  (Things like :TI markers for VLIW bundles
> could use a separate flag instead.)
Dunno offhand.  I'm OK with things as-is for now -- again, having
classes allows us to real wrappers and enforce a degree to access
control, which greatly diminishes the pain we had with var_ann.

Splitting off rtx_insn from rtx is independent, but definitely something
I want to see move forward.

Jeff