public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jim Wilson <wilson@codesourcery.com>
To: "Amker.Cheng" <amker.cheng@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Question on mips multiply patterns in md file
Date: Mon, 15 Mar 2010 22:03:00 -0000	[thread overview]
Message-ID: <4B9E9ACF.1000707@codesourcery.com> (raw)
In-Reply-To: <e8b251c81003150100v66a7f8baj89bca64b11708827@mail.gmail.com>

On 03/15/2010 01:00 AM, Amker.Cheng wrote:
> 1:  In pattern "*mul_acc_si", there's constraint like "*?*?".
> what does this supposed to do?

'*' is in the Constraint Modifier Characters section of the docs.  It 
means ignore the next character for register class preferencing.  '?' is 
in the Multiple Alternative Constraints section.  It means that this 
alternative is less desirable than the others.  So '*?' will be ignored 
by the register class preferencing code.  It will be used in reload when 
computing which alternative is better though.  Reload computes a cost 
for each alternative, and then chooses the cheapest one, or which ever 
one occurs first (left to right) when there are ties.  '*?' has the 
effect of slightly increasing the reload cost of an alternative, and is 
used when you want to discourage reload from picking this particular 
alternative.

If you don't know anything about register class preferencing or reload 
as yet, then this is probably not going to make much sense to you, but 
it isn't anything important you need to worry about at this point.  It 
is a very minor performance optimization.

> 2:  there is a split pattern for "*mul_acc_si" as following:
> this will generate integer multiply instruction with register write,
> but what if the processor has only integer multiply instructions,
> which only store results in HILO?

A define_split can only match something generated by a define_insn, and 
the mul_acc_si define_insn is testing "GENERATE_MADD_MSUB && !TARGET_MIPS16"
so there is no serious problem.  We are just running a define_split that 
can never match anything.  This could be cleaned up a little by adding 
an appropriate condition to the define_split, or by combining the 
define_insn and define_split patterns into a define_insn_and_split pattern.

Jim

  reply	other threads:[~2010-03-15 20:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15  8:52 Amker.Cheng
2010-03-15 22:03 ` Jim Wilson [this message]
2010-03-16  8:55   ` Amker.Cheng
2010-03-17 20:22     ` Jim Wilson
2010-03-18 11:23       ` Amker.Cheng
2010-03-18 22:58         ` Jim Wilson

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=4B9E9ACF.1000707@codesourcery.com \
    --to=wilson@codesourcery.com \
    --cc=amker.cheng@gmail.com \
    --cc=gcc@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).