public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Georg-Johann Lay <avr@gjlay.de>
To: Richard Henderson <rth@redhat.com>
Cc: gcc-patches@gcc.gnu.org, Anatoly Sokolov <aesok@post.ru>,
	 Denis Chertykov <chertykov@gmail.com>,
	Eric Weddington <eric.weddington@atmel.com>
Subject: Re: [Patch,AVR]: Solve PR42210
Date: Mon, 16 May 2011 18:33:00 -0000	[thread overview]
Message-ID: <4DD14860.7090102@gjlay.de> (raw)
In-Reply-To: <4DB7E392.7060001@gjlay.de>

Georg-Johann Lay schrieb:
> Richard Henderson schrieb:
> 
>> Why are you adding "optimize" to all these insns?  None of them will
>> be matched unless combine is run, which implies optimization.
> 
> Here is a patch without optimize in the insn conditions.
> 
> The optimize condition is still present in the insv expander because I
> do not know what the policy about that is in the avr backend.
> 
> Johann
> 
>> r~
>>
> 
> 	PR target/42210
> 
> 	* config/avr/predicates.md (const1_operand, const_0_to_7_operand):
> 	New predicates.
> 	
> 	* config/avr/avr.md ("insv"): New insn expander.
> 	("*movbitqi.1-6.a", "*movbitqi.1-6.b", "*movbitqi.0", "*insv.io",
> 	"*insv.not.io", "*insv.reg"): New insns.
> 

Patch:
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02099.html

As Denis wrote in
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00081.html
some pattern are too hard to understand. Presumably that are the
patches that open-code some bit insertions.

Would the path, be ok without these patterns, namely without

"*movbitqi.1-6.a"
"*movbitqi.1-6.b"
"*movbitqi.0"
"*movbitqi.7"

A am still of the opinion that avr should make use of insn combine and
it's power. If these patterns are too hard to understand I can add
some more comments and explanations.

The insv-like patterns are plain vanilla

"insv"
"*insv.io"
"*insv.reg"

These patterns are likely on machines that come with bitfield
representations for SFRs. On targets where just SFR addresses and bit
positions are available, bit insertions and extractions are open coded
by bunch of or-and-not-mask arithmetic, so it's not unlikely to see
them in the insn stream. Moreover, RTL lowering won't use insv on
volatile mem, just combiner can do that magic. Without the patch there
are places where a long, slow 16-bit(!) shift is used requiring a
bulky slow loop.

If you sag what patterns are ok an which are not, I will make an
according patch. (Without combine bridges other patterns might be
dead, because combine doesn't look deep enough).

Johann


  parent reply	other threads:[~2011-05-16 15:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-20 18:12 Georg-Johann Lay
2011-04-21 13:00 ` Georg-Johann Lay
2011-04-21 19:24   ` Richard Henderson
2011-04-26 12:59     ` Georg-Johann Lay
2011-04-26 15:28       ` Richard Henderson
2011-04-26 15:39         ` Georg-Johann Lay
2011-04-27 10:33         ` Georg-Johann Lay
2011-05-02  9:29           ` Ping #1: " Georg-Johann Lay
2011-05-16 18:33           ` Georg-Johann Lay [this message]
2011-05-28 19:09             ` Georg-Johann Lay
2011-06-04  6:56               ` Denis Chertykov

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=4DD14860.7090102@gjlay.de \
    --to=avr@gjlay.de \
    --cc=aesok@post.ru \
    --cc=chertykov@gmail.com \
    --cc=eric.weddington@atmel.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rth@redhat.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).