On 9/10/23 00:49, Hongyu Wang wrote:
Vladimir Makarov via Gcc-patches <gcc-patches@gcc.gnu.org> 于2023年9月9日周六 01:04写道：
On 8/31/23 04:20, Hongyu Wang wrote:
@@ -2542,6 +2542,8 @@ the code of the immediately enclosing expression
(@code{MEM} for the top level
of an address, @code{ADDRESS} for something that occurs in an
@code{address_operand}). @var{index_code} is the code of the corresponding
index expression if @var{outer_code} is @code{PLUS}; @code{SCRATCH}
otherwise.
+@code{insn} indicates insn specific base register class should be subset
+of the original base register class.
@end defmac
I'd prefer more general description of 'insn' argument for the macros.
Something like that:
@code{insn} can be used to define an insn-specific base register class.
Sure, will adjust in the V2 patch.
Also, currently we reuse the old macro MODE_CODE_BASE_REG_CLASS, do
you think we need a new macro like INSN_BASE_REG_CLASS as other
parameters are actually unused? Then we don't need to change other
targets like avr/gcn.
I thought about this too. Using new macros would be definitely worth to
add, especially when you are already adding INSN_INDEX_REG_CLASS.
The names INSN_BASE_REG_CLASS instead of MODE_CODE_BASE_REG_CLASS and
REGNO_OK_FOR_INSN_BASE_P instead of REGNO_MODE_CODE_OK_FOR_BASE_P are ok
for me too.
When you submit the v2 patch, I'll review the RA part as soon as
possible (actually I already looked at this) and most probably give my
approval for the RA part because I prefer you current approach for RA
instead of introducing new memory constraints.
