Hi,
So, you talk about gen_thumb1_extendhisi2, but there is also
gen_thumb1_extendqisi2. Will it actually be cleaner if the block is
indented one level?
The comment can be added in the "if (TARGET_THUMB1)" block regardless to
indicate that gen_rtx_SIGN_EXTEND can't be used.
gen_rtx_SIGN_EXTEND (I see I used wrong caps above before sorry!) will
work for the case of QImode -> SImode for Thumb1. The reason it doesn't
work for HImode -> SImode in thumb1 is because thumb1_extendhisi2 uses a
scratch register, see:
(define_insn "thumb1_extendhisi2"
[(set (match_operand:SI 0 "register_operand" "=l,l")
(sign_extend:SI (match_operand:HI 1 "nonimmediate_operand" "l,m")))
(clobber (match_scratch:SI 2 "=X,l"))]
meaning that the pattern generated with gen_rtx_SIGN_EXTEND:
[(set (SImode ...) (sign_extend:SImode (HImode))]
Does not match this and there are no other thumb1 patterns that match
this either, so the compiler ICEs. For thumb1_extendqisi2 the pattern
doesn't have the scratch register so a:
gen_rtx_SET (<rtx:SImode>, gen_rtx_SIGN_EXTEND (SImode, <rtx:QImode>))
will generate a rtl pattern that will match thumb1_extendqisi2.
Hope that makes it clearer.
Whit the patch you have in mind, will it be possible to call
gen_rtx_SIGN_EXTEND for THUMB1 too? Or do we need to keep calling
thumb1_extendhisi2 and thumb1_extendqisi2?
With patch I have in mind, and will post soon, you could use
gen_rtx_SIGN_EXTEND for HImode in thumb1, like I explained before for
QImode its already possible.
That series will have another patch that also removes all calls to
gen_thumb1_extend* and replaces them with gen_rtx_SET +
gen_rtx_SIGN_EXTEND and renames the "thumb1_extend{hisi2,qisi1} patterns
to "*thumb1_extend{hisi2,qisi2}".
However, that patch we won't backport, but yours we should hence why
it's worth having your patch with the thumb1_extendhisi2 workaround.
Thanks,
Andre
