public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Cherry Vanc <cherry.vanc@gmail.com>, gcc-help@gcc.gnu.org
Subject: Re: help with fusing multiple dependent ops in gcc combine pass
Date: Fri, 15 Aug 2014 05:16:00 -0000	[thread overview]
Message-ID: <53ED978E.4050300@redhat.com> (raw)
In-Reply-To: <CANqEaAeehJ6BcWV4s8tMd+h6Ka+ybOCMOdMVV2VZGEFCB2=6Yg@mail.gmail.com>

On 08/14/14 19:21, Cherry Vanc wrote:
>   I received very helpful comments previously
> (https://gcc.gnu.org/ml/gcc-help/2014-08/msg00010.html). And I could
> successfully fuse dependent ops like following :
>
> ...
> r1 = (r1) op1 (const)
> ...
> ...
> r1 = (r1) op2 (r2)
> ...
> ...
> r3 = op3 (r1)
> ...
>
> using a define_insn pattern to a new op "testnew36".
>
> Now, How can I fuse the following stream of ops :
>
> ...
> op1
> ...
> op2 (consumes result of op1)
> ...
> op3 (consumes result of op2)
> ...
> op4 (consumes result of op2)
> ...
>
> to the following :
>
> ...
> testnew36
> ...
> testnew40
>
> The pertinent pattern seen in .combine file is a parallel expression :
>
> (parallel [
>          (set (reg:DI 256 [ *_15 ])
>              (op3:DI (op2:DI (op1:DI (reg:DI 202 [ D.1563 ])
>                          (const_int 4 [0x4]))
>                      (reg:DI 242 [ inbuf ])) ))
>          (set (reg:DI 205 [ D.1566 ])
>              (op2:DI (op1:DI (reg:DI 202 [ D.1563 ])
>                      (const_int 4 [0x4]))
>                  (reg:DI 242 [ inbuf ])))
>      ])
If you see a PARALLEL, then it means that one of the output operands in 
the original series of insns is used later.     Thus that side effect 
must be preserved.  In the example above, you'll find uses of regs 256 
and 205.

PARALLELs are typically far less useful because targets typically don't 
have many instructions that produce multiple outputs.  Typically when a 
PARALLEL is generated, you're going to be outputting multiple 
instructions for the PARALLEL.  In that case you're better off using a 
define_insn_and_split.  You can find many examples in the various MD 
files distributed with GCC.

If all the intermediate destinations die when they are consumed, then 
the combiner will not need to preserve the side effects and thus won't 
generate a PARALLEL and you would implement that as a simple define_insn 
in the machine description.  Again, you can find many examples of 
patterns for the combiner in the various MD files included in GCC.


Jeff


      reply	other threads:[~2014-08-15  5:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-15  1:21 Cherry Vanc
2014-08-15  5:16 ` Jeff Law [this message]

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=53ED978E.4050300@redhat.com \
    --to=law@redhat.com \
    --cc=cherry.vanc@gmail.com \
    --cc=gcc-help@gcc.gnu.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).