[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
Feng Wang changed:
What|Removed |Added
CC||wangfeng at eswincomputing dot
com
--- Comment #1 from Feng Wang ---
Hi Jeff,
I have modified some code according to your suggestion.
In simplify-rtx.cc I add below part in canonicalize_shift:
if ((code == ASHIFTRT)
&& is_a (mode, &int_mode)
&& GET_CODE (op0) == ASHIFT
&& CONST_INT_P (op1)
&& is_a (GET_MODE (op0), &inner_mode)
&& CONST_INT_P (XEXP (op0, 1))
&& (INTVAL (XEXP (op0, 1)) == INTVAL (op1)))
{
tem = XEXP (op0, 0);
if (SUBREG_P(XEXP (op0, 0))
&& is_a (GET_MODE (SUBREG_REG (XEXP (op0, 0))),
&inner_mode)
&& GET_MODE_BITSIZE (inner_mode) > GET_MODE_BITSIZE (int_mode))
{
tem = XEXP (XEXP (op0, 0), 0);
}
if ((INTVAL (op1) + 8 == 32) || (INTVAL (op1) + 8 == 64))
{
op0 = lowpart_subreg (E_QImode, tem, GET_MODE(tem));
return simplify_gen_unary (SIGN_EXTEND, int_mode, op0, int_mode);
}
if ((INTVAL (op1) + 16 == 32) || (INTVAL (op1) + 16 == 64))
{
op0 = lowpart_subreg (E_HImode, tem, GET_MODE(tem));
return simplify_gen_unary (SIGN_EXTEND, int_mode, op0, int_mode);
}
}
and at the same time in fwprop.cc I add below conditions in classify_result to
judge whether replacement is PROFITABLE
/* If have load byte or load half pattern, we can covert
ashiftrt(ashift(object)const)const to load byte or half form object */
if (GET_CODE(old_rtx) == ASHIFTRT
&& GET_CODE(new_rtx) == SIGN_EXTEND
&& (GET_MODE(new_rtx) == E_SImode
&& (((GET_MODE(XEXP(new_rtx, 0)) == E_QImode)
&& HAVE_extendqisi2)
|| ((GET_MODE(XEXP(new_rtx, 0)) == E_HImode)
&& HAVE_extendhisi2)))
|| (GET_MODE(new_rtx) == E_DImode
&& (((GET_MODE(XEXP(new_rtx, 0)) == E_QImode)
&& HAVE_extendqidi2)
|| ((GET_MODE(XEXP(new_rtx, 0)) == E_HImode)
&& HAVE_extendhidi2
return PROFITABLE;
Please check if it is reasonable and look forward to further discussion with
you.Thanks!
[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #2 from Feng Wang ---
(In reply to Feng Wang from comment #1)
> Hi Jeff,
>
> I have modified some code according to your suggestion.
> In simplify-rtx.cc I add below part in canonicalize_shift:
> if ((code == ASHIFTRT)
> && is_a (mode, &int_mode)
> && GET_CODE (op0) == ASHIFT
> && CONST_INT_P (op1)
> && is_a (GET_MODE (op0), &inner_mode)
> && CONST_INT_P (XEXP (op0, 1))
> && (INTVAL (XEXP (op0, 1)) == INTVAL (op1)))
> {
> tem = XEXP (op0, 0);
> if (SUBREG_P(XEXP (op0, 0))
> && is_a (GET_MODE (SUBREG_REG (XEXP (op0,
> 0))),
> &inner_mode)
> && GET_MODE_BITSIZE (inner_mode) > GET_MODE_BITSIZE (int_mode))
> {
> tem = XEXP (XEXP (op0, 0), 0);
> }
>
> if ((INTVAL (op1) + 8 == 32) || (INTVAL (op1) + 8 == 64))
> {
> op0 = lowpart_subreg (E_QImode, tem, GET_MODE(tem));
> return simplify_gen_unary (SIGN_EXTEND, int_mode, op0, int_mode);
> }
>
> if ((INTVAL (op1) + 16 == 32) || (INTVAL (op1) + 16 == 64))
> {
> op0 = lowpart_subreg (E_HImode, tem, GET_MODE(tem));
> return simplify_gen_unary (SIGN_EXTEND, int_mode, op0, int_mode);
> }
> }
>
> and at the same time in fwprop.cc I add below conditions in classify_result
> to judge whether replacement is PROFITABLE
> /* If have load byte or load half pattern, we can covert
> ashiftrt(ashift(object)const)const to load byte or half form object */
> if (GET_CODE(old_rtx) == ASHIFTRT
> && GET_CODE(new_rtx) == SIGN_EXTEND
> && ((GET_MODE(new_rtx) == E_SImode
>&& ((GET_MODE(XEXP(new_rtx, 0)) == E_QImode
> && HAVE_extendqisi2)
> || (GET_MODE(XEXP(new_rtx, 0)) == E_HImode
> && HAVE_extendhisi2)))
> ||(GET_MODE(new_rtx) == E_DImode
>&& ((GET_MODE(XEXP(new_rtx, 0)) == E_QImode
> && HAVE_extendqidi2)
> || (GET_MODE(XEXP(new_rtx, 0)) == E_HImode
> && HAVE_extendhidi2
> return PROFITABLE;
>
> Please check if it is reasonable and look forward to further discussion with
> you.Thanks!
[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592 --- Comment #5 from Feng Wang --- I found something interesting, these operations such as zero_extend,sign_extend,zero_extract,sign_extract will be considered as compound operation and will transform to the approriate shifts and AND operations(This proc is in expand_compound_operation). So if the sign_extend op generated earlier,it will be converted by expand_compound_operation again during the after pass such as combine pass. In the combine pass, it will perform the opposite operation as above.Through make_compound and make_extraction functions two shifts insns will combine into sign_extend or zero_extend if the pattern exist,and then judge the cost of it.It is profitable replacement only when the arch supports sign_extend and costs less than two shifts insns. So I think the first patch is enough, https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg303789.html it handles the introduction of subregs when compiling and processing 32-bit using a 64 bit compiler. The first patch process the below rtl. (set (reg:SI 137) (ashiftrt:SI (subreg:SI (ashift:DI (reg:DI 140) (const_int 24 [0x18])) 0) (const_int 24 [0x18]))) During extract_left_shift processing,it wants to get reg:DI 140,but now the extraction is failed due to the subreg is in the front of the ashift. So I think we just need jump the subreg is enough to ensure normal subsequent processing.
[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592 --- Comment #8 from Feng Wang --- (In reply to Jeffrey A. Law from comment #7) > Attached is what I cobbled together. It doesn't use magic numbers. But it > doesn't yet handle zero extensions in the simplify-rtx code. But I think it > shows the overall direction fairly well. Sorry, I can't find the attachement. I think we need to consider more here,such as the cost of zero/sign extensions, only convert shifts to zero/sign extensions when it cost less in certain hardware architectures. At the same we also consider the shift ins is more suitable for combine pass.Maybe We should consider that whether the conversion prevents a better combination in combine pass(I need study a suitable test case).
[Bug target/117669] RISC-V:The 'VEEWTRUNC4' iterator 'RVVMF2BF' type condition error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117669 Feng Wang changed: What|Removed |Added CC||wangfeng at eswincomputing dot com --- Comment #1 from Feng Wang --- That's fantastic!Thanks for your pointing this error.
