This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] RL78 one_cmplhi2 improvement
- From: "Sebastian Perta" <sebastian dot perta at renesas dot com>
- To: "'DJ Delorie'" <dj at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 27 Feb 2018 15:33:29 -0000
- Subject: RE: [PATCH] RL78 one_cmplhi2 improvement
- Authentication-results: sourceware.org; auth=none
- References: <000501d3aa44$69a44e30$3cecea90$@renesas.com> (sebastian.perta@renesas.com) <xnbmgjjvs4.fsf@greed.delorie.com>
HI DJ,
> One thing to try is to use (subreg:QI in a define_expand, so that
> there's a one_cmplhi2 pattern that expands to two QImode insns that
> operate on HImode input/outputs via SUBREGs.
Thank you for the suggestion! After several attempts the following is the
only successful one, however the code produced is identical with and without
the patch:
(define_expand "one_cmplhi2"
[(set (subreg:QI (match_operand:HI 0 "nonimmediate_operand") 0)
(xor:HI (subreg:QI (match_operand:HI 1 "general_operand") 0)
(const_int -1)))
(set (subreg:QI (match_dup 0) 1)
(xor:HI (subreg:QI (match_dup 1) 1)
(const_int -1)))
]
""
"DONE;"
)
Is this similar to what you had in mind?
Output code (same as before the patch ... the patch makes no difference):
_test_one_cmplhi:
mov a, [sp+4]
xor a, #-1
mov r8, a
mov a, [sp+5]
xor a, #-1
mov r9, a
ret
I also explored other options including define_split without any success.
> If it doesn't work out, consider this patch approved, though.
Can I checkin now?
Best Regards,
Sebastian
> -----Original Message-----
> From: DJ Delorie [mailto:dj@redhat.com]
> Sent: 20 February 2018 19:39
> To: Sebastian Perta <Sebastian.Perta@renesas.com>
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] RL78 one_cmplhi2 improvement
>
>
> Const type promotion is the bane of embedded developers...
>
> One thing to try is to use (subreg:QI in a define_expand, so that
> there's a one_cmplhi2 pattern that expands to two QImode insns that
> operate on HImode input/outputs via SUBREGs.
>
> I don't have high hopes of gcc optimizing this properly in all cases,
> but it's worth trying.
>
> If it doesn't work out, consider this patch approved, though.
>
> Thanks!