public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Jozef Lawrynowicz <jozefl.gcc@gmail.com>, gcc@gcc.gnu.org
Subject: Re: peephole or expand optimization for fixing poor code generated in conversion from QImode to PSImode pointer?
Date: Mon, 23 Sep 2019 13:30:00 -0000	[thread overview]
Message-ID: <85423133-b80f-d443-050f-0e02edceafd2@redhat.com> (raw)
In-Reply-To: <20190923125620.2e82128c@jozef-kubuntu>

On 9/23/19 5:56 AM, Jozef Lawrynowicz wrote:
> For msp430-elf in the large memory model there are PSImode (20-bit) pointers.
> POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default.
> 
> We get poor code generated for the following code snippet:
> 
> const int table[2] = {1, 2};
> 
> int
> foo (char i)
> {
>   return table[i];
> }
> 
> The RTL generated by expand uses two insns to convert "i" to a register's
> natural mode; there is a sign extension which would be unnecessary if the first
> instruction had a PSImode register as the lvalue:
> 
> (insn 2 4 3 2 (set (reg/v:HI 25 [ i ])
>         (zero_extend:HI (reg:QI 12 R12 [ i ])))
>      (nil))
> .....
> (insn 7 6 8 2 (set (reg:PSI 28)
>         (subreg:PSI (sign_extend:SI (reg/v:HI 25 [ i ])) 0))
>      (nil))
> 
> All we really need is:
> 
> (insn (set (reg:PSI 28 [ i ])
>         (zero_extend:PSI (reg:QI 12 R12 [ i ])))
>      (nil))
> 
> The zero extend is implicit with byte sized register operations, so this would
> result in assembly such as:
>   MOV.B R12, R12
> 
> My question is whether this is the type of thing that should be handled with a
> peephole optimization or if it is worth trying to fix the initial RTL generated
> by expand (or in a later RTL pass e.g. combine)?
Ideally it'd be fixed earlier, but that can be painful due to the way
promotions work.

I certainly recall doing some combiner patterns to catch the more
egregious codegen issues on the mn102 port (similar, but with 24bit
pointers).  I think I mostly focused on stuff that showed up with
integer loop indices and their annoying promotion to ptrdiff_t when used
for array indexing.

I'd bet if you extracted mn10200.md out of the archive the patterns
would be obvious ;-)

In this specific case I'd think a combiner pattern ought to do the right
thing except for the fact that you're probably dealing with hard
registers which combine no longer handles as aggressively.

jeff

  parent reply	other threads:[~2019-09-23 13:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-23 11:56 Jozef Lawrynowicz
2019-09-23 13:25 ` Richard Biener
2019-09-23 13:30 ` Jeff Law [this message]
2019-09-23 17:02   ` Jozef Lawrynowicz
2019-09-23 15:56 ` Segher Boessenkool
2019-09-23 17:56   ` Jozef Lawrynowicz
2019-09-23 22:53     ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85423133-b80f-d443-050f-0e02edceafd2@redhat.com \
    --to=law@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jozefl.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).