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 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.) It might even be possible to do the update fairly cheaply, if we made the generators record static flags for the fixed part of the pattern and only computed the operand information dynamically. Thanks, Richard
