public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@imgtec.com>
To: "Kumar, Venkataramanan" <Venkataramanan.Kumar@amd.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	"Jeff Law (law@redhat.com)" <law@redhat.com>,
	"gcc-patches@gcc.gnu.org"	<gcc-patches@gcc.gnu.org>,
	"maxim.kuvyrkov@linaro.org"	<maxim.kuvyrkov@linaro.org>,
	Matthew Fortune <Matthew.Fortune@imgtec.com>,
	clm <clm@codesourcery.com>
Subject: RE: [RFC]: Remove Mem/address type assumption in combiner
Date: Mon, 11 May 2015 17:50:00 -0000	[thread overview]
Message-ID: <1431366602.14613.210.camel@ubuntu-sellcey> (raw)
In-Reply-To: <7794A52CE4D579448B959EED7DD0A4723DCF68C1@satlexdag06.amd.com>

On Thu, 2015-05-07 at 11:01 +0000, Kumar, Venkataramanan wrote:
> Hi Segher, 
> 
> Thank you I committed as r222874. 
> Ref: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222874
> 
> Regards,
> Venkat.


Venkat,

This patch broke a number of MIPS tests, specifically mips32r6 tests
that look for the lsa instruction (load scaled address) which shifts one
register and then adds it to a second register.  I am not sure if this
needs to be addressed in combine.c or if we need to add a peephole
optimization to mips.md to handle the new instruction sequence.  What do
you think?  Is the change here what you would expect to see from your
patch?

With this C code:


signed short test (signed short *a, int index)
{
  return a[index];
}


GCC/combine for mips32r6 used to produce:

(insn 8 7 9 2 (set (reg/f:SI 203)
        (plus:SI (mult:SI (reg:SI 5 $5 [ index ])
                (const_int 2 [0x2]))
            (reg:SI 4 $4 [ a ]))) lsa.c:3 444 {lsa}
     (expr_list:REG_DEAD (reg:SI 5 $5 [ index ])
        (expr_list:REG_DEAD (reg:SI 4 $4 [ a ])
            (nil))))
(insn 15 10 16 2 (set (reg/i:SI 2 $2)
        (sign_extend:SI (mem:HI (reg/f:SI 203) [1 *_5+0 S2 A16])))
lsa.c:4 237 {*extendhisi2_seh}
     (expr_list:REG_DEAD (reg/f:SI 203)
        (nil)))

And would generate:

	lsa	$4,$5,$4,1
	lh	$2,0($4)
	

But now it produces:

(insn 7 4 8 2 (set (reg:SI 202)
        (ashift:SI (reg:SI 5 $5 [ index ])
            (const_int 1 [0x1]))) lsa.c:3 432 {*ashlsi3}
     (expr_list:REG_DEAD (reg:SI 5 $5 [ index ])
        (nil)))
(insn 8 7 9 2 (set (reg/f:SI 203)
        (plus:SI (reg:SI 4 $4 [ a ])
            (reg:SI 202))) lsa.c:3 13 {*addsi3}
     (expr_list:REG_DEAD (reg:SI 4 $4 [ a ])
        (expr_list:REG_DEAD (reg:SI 202)
            (nil)))
(insn 15 10 16 2 (set (reg/i:SI 2 $2)
        (sign_extend:SI (mem:HI (reg/f:SI 203) [1 *_5+0 S2 A16])))
lsa.c:4 237 {*extendhisi2_seh}
     (expr_list:REG_DEAD (reg/f:SI 203)
        (nil)))

Which generates:

	sll	$5,$5,1
	addu	$4,$4,$5
	lh	$2,0($4)




Steve Ellcey
sellcey@imgtec.com


  reply	other threads:[~2015-05-11 17:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-29  9:29 Kumar, Venkataramanan
2015-04-29 17:38 ` Segher Boessenkool
2015-04-29 19:23   ` Jeff Law
2015-05-01 15:18   ` Segher Boessenkool
2015-05-05 16:14     ` Kumar, Venkataramanan
2015-05-05 17:15       ` Segher Boessenkool
2015-05-07 11:01         ` Kumar, Venkataramanan
2015-05-11 17:50           ` Steve Ellcey [this message]
2015-05-11 18:27             ` Segher Boessenkool
2015-05-11 19:44               ` Steve Ellcey
2015-05-11 19:46                 ` Jeff Law
2015-05-11 19:46                   ` Jeff Law
2015-05-11 20:17                     ` Matthew Fortune
2015-05-11 20:30                       ` Segher Boessenkool
2015-05-11 20:54                         ` Matthew Fortune
2015-05-12  6:43             ` Kumar, Venkataramanan
2015-05-12 16:57               ` Steve Ellcey
2015-05-12 22:02                 ` Moore, Catherine
2015-05-16  6:09     ` Hans-Peter Nilsson
2015-05-16 14:36       ` Segher Boessenkool
2015-05-16 16:43         ` Hans-Peter Nilsson
2015-05-16 17:40           ` Segher Boessenkool
2015-05-17  8:53             ` Hans-Peter Nilsson
2015-05-17 13:32               ` Segher Boessenkool
2015-05-17 13:48                 ` Hans-Peter Nilsson
2015-05-19 17:30               ` Jeff Law
2015-04-29 19:22 ` Jeff Law
2015-04-29 19:31 ` Jeff Law

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=1431366602.14613.210.camel@ubuntu-sellcey \
    --to=sellcey@imgtec.com \
    --cc=Matthew.Fortune@imgtec.com \
    --cc=Venkataramanan.Kumar@amd.com \
    --cc=clm@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=segher@kernel.crashing.org \
    /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).