This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/4] gcc/arc: Remove load_update_operand predicate




On 16/12/15 00:15, Andrew Burgess wrote:
	* config/arc/arc.md (*loadqi_update): Use 'memory_operand' and fix
	RTL pattern to include the plus.
	(*load_zeroextendqisi_update): Likewise.
	(*load_signextendqisi_update): Likewise.
	(*loadhi_update): Likewise.
	(*load_zeroextendhisi_update): Likewise.
	(*load_signextendhisi_update): Likewise.
	(*loadsi_update): Likewise.
	(*loadsf_update): Likewise.
	* config/arc/predicates.md (load_update_operand): Delete.

Store_update_operand has the very same problem, so it would make sense to fix that
in the same check-in.
FWIW, while using "memory_operand" makes for simple source code, it introduces duplicated checks (and they are appropriate only because the the update and some of the non-update addressing modes on the ARC are different modes of the same encoding). It checks that the inside of the MEM is a valid memory address, which is redundant with the pattern-provided checks that there's a plus with appropriate base and index/update
operand inside.
Also, by using memory_operand, you are adding a check to reject volatile memory operands
during most optimization passes.
Note that ARC's move_src_operand and move_dest_operand are fine with volatile MEMs
irrespective of the setting of volatile_ok.
Problems with volatiles can rally only be expected if there are multiple MEMs in a single pattern, that might alias, arithmetic on MEM that might result from simplifications using a different set of MEMs, or if the machine instructions that a pattern corresponds to are intrinsically unsuitable for
volatile.
Needlessly rejecting volatile MEMs will reduce optimization potential; this tends to be more visible on embedded platforms than with embedded code than with typical workstation code.

Less reliance on this addressing modes orthogonality, no change of volatile behaviour, and maybe a slightly faster compiler, would be to just have an "update_operand" or "any_mem_operand" predicate checking that the inside is a MEM. and leave the address
processing entirely to the instruction pattern and its operand predicates.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]