public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Jonas Paulsson" <d03jp@student.lth.se>
To: "Hans-Peter Nilsson" <hans-peter.nilsson@axis.com>
Cc: d03jp@student.lth.se, radu.hobincu@arh.pub.ro, gcc@gcc.gnu.org
Subject: Re: GCC porting tutorials
Date: Tue, 27 Apr 2010 19:32:00 -0000	[thread overview]
Message-ID: <59949.90.237.230.43.1272393707.squirrel@webmail.student.lth.se> (raw)
In-Reply-To: <201004270401.o3R41xZ8012337@ignucius.se.axis.com>


I've been following the discussion a bit about contributing, and find
myself here now even directly pointed at :-) As I mentioned, I am not very
experienced with GCC, for one thing I have not studied other ports very
much. To make a GCC patch for this problem to be generally handled is then
a bit over my head, but perhaps with some mentoring from someone with
enough experience, I could give it a try!

Problem: even if a widening pattern is defined in the .md-file, it may not
end up being used, as it should per definition if it is prior to other
mul-patterns in the file. If it is located afterwards, then it may be a
matter of discussion, if one would not like to consider these preferable.

The solution of handling this during expansion that I used, is not wrong
the way I see it. Since more than one Gimple pass is involved in this
problem - rewriting the code so that the RTL-expander will use a wide
mult-insn - it seems quite logical to simply undo this during expansion in
terms of reactivating the original operands. Much simpler to have this fix
in one place, as it is a bit of a side issue, I think.

I would like to see that all widening mult-patterns defined prior to wide
mult-patterns in the .md file, end up being used when feasable - this is
logical.

An extended solution to what I used could perhaps do this work prior to
emitting wide mult-insns:

1. initialization: generate extension RTL, so that the extending insns
(lists) can be recognized on each target.

2. prior to expanding a multiplication:

if widening mult-pattern that suits the mode is defined
   try to find both operands origins of extension per point 1.
   if both operands extended:
	emit widening pattern
else
	emit wide pattern

I am not certain this is a complete solution, it is merely my immediate
thoughts, so please correct me. If somebody believes in correcting this
GCC behaviour and have the time to guide me, I would be happy to
participate.

/Jonas


>> From: "Jonas Paulsson" <d03jp@student.lth.se>
>> Date: Mon, 26 Apr 2010 11:07:04 +0200
>
>> I recently completed my degree project on LTH on retargeting GCC. See
>> http://sam.cs.lth.se/ExjobGetFile?id=224 for my report (it will be moved
>> to
>> http://cs.lth.se/examensarbete/rapporter/rapporter_2010/ soon).
>
> Interesting observations there; I wish there was incentive for
> you to actually resolve them the right way in GCC, meaning this
> project.
>
> I've recently been bitten by the lost-widening-multiplication-
> when-in-loop issue myself, and noted it for revisit Some Day.
> Fixing that by other means made a whopping 27% improvement for
> the application where I saw it: a hot loop doing a MDCT using
> Q31 fixed-point, where a common operation is to widen-multiply
> two 32-bit numbers and pick the high 32 bits of the 64-bit
> result (being the result divided by 2; i.e. Q30-ish for that
> operation).
>
> brgds, H-P
>


  reply	other threads:[~2010-04-27 18:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-24  9:05 Radu Hobincu
2010-04-24  9:17 ` Sergio Ruocco
2010-04-24  9:49 ` Michael Hope
2010-04-24 15:01 ` Ian Lance Taylor
2010-04-24 16:27   ` Bernd Roesch
2010-04-26  9:14 ` Jonas Paulsson
2010-04-26 12:13   ` Radu Hobincu
2010-04-27  4:46   ` Hans-Peter Nilsson
2010-04-27 19:32     ` Jonas Paulsson [this message]
2010-04-28 17:22       ` Widening multiplications (was: Re: GCC porting tutorials) Hans-Peter Nilsson
2010-04-28 21:27       ` GCC porting tutorials Bernd Schmidt
2010-04-29  7:07         ` Jonas Paulsson
2010-04-30  1:58           ` Parallelized loads and widening mults cont:ed (was: Re: GCC porting tutorials) Hans-Peter Nilsson

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=59949.90.237.230.43.1272393707.squirrel@webmail.student.lth.se \
    --to=d03jp@student.lth.se \
    --cc=gcc@gcc.gnu.org \
    --cc=hans-peter.nilsson@axis.com \
    --cc=radu.hobincu@arh.pub.ro \
    /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).