On 12/14/20 9:37 AM, Richard Sandiford wrote:
> Jeff Law <l...@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
