GCC porting tutorials

GCC porting tutorials

[Radu Hobincu]

Hello,

My name is Radu Hobincu, I am part of a team at "Politehnica" University
of Bucharest that is developing a massive parallel computing architecture
and currently my job is to port the GCC compiler to this new machine.

I've been looking over the GCC official site at http://gcc.gnu.org/ but I
couldn't find an official porting tutorial. Is there such a thing? And
maybe a small example for a lightweight architecture?

Regards,
Radu

Re: GCC porting tutorials

[Sergio Ruocco]

Hi Radu,

Check both the GCC Wiki and the work done at IIT Bombay:
http://www.cse.iitb.ac.in/grc/reach.html
Activities->Workshops

They developed some tutorials on porting GCC and writing new backends, such as:
http://www.cse.iitb.ac.in/grc/gcc-workshop-09/
http://www.cse.iitb.ac.in/~uday/gcc-mini-workshop/


On 24 April 2010 10:53, Radu Hobincu <radu.hobincu@arh.pub.ro> wrote:
> Hello,
>
> My name is Radu Hobincu, I am part of a team at "Politehnica" University
> of Bucharest that is developing a massive parallel computing architecture
> and currently my job is to port the GCC compiler to this new machine.
>
> I've been looking over the GCC official site at http://gcc.gnu.org/ but I
> couldn't find an official porting tutorial. Is there such a thing? And
> maybe a small example for a lightweight architecture?
>
> Regards,
> Radu
>

Re: GCC porting tutorials

[Michael Hope]

Hi Radu.  I found the MMIX backend to be quite useful.  It's
reasonably small and acceptably up to date.  Keep in mind that the
MMIX is a 64 bit machine though.

The Picochip and ARM are good as well.  The ARM port is very
complicated due to the number of targets that it supports but fairly
clean once you get into it.

-- Michael

On 24 April 2010 20:53, Radu Hobincu <radu.hobincu@arh.pub.ro> wrote:
> Hello,
>
> My name is Radu Hobincu, I am part of a team at "Politehnica" University
> of Bucharest that is developing a massive parallel computing architecture
> and currently my job is to port the GCC compiler to this new machine.
>
> I've been looking over the GCC official site at http://gcc.gnu.org/ but I
> couldn't find an official porting tutorial. Is there such a thing? And
> maybe a small example for a lightweight architecture?
>
> Regards,
> Radu
>

Re: GCC porting tutorials

[Ian Lance Taylor]

"Radu Hobincu" <radu.hobincu@arh.pub.ro> writes:

> I've been looking over the GCC official site at http://gcc.gnu.org/ but I
> couldn't find an official porting tutorial. Is there such a thing? And
> maybe a small example for a lightweight architecture?

I don't know of a tutorial, but I want to make sure that you are
looking at the internal docs: http://gcc.gnu.org/onlinedocs/gccint/ .
They include the information you need for a new port, though not
organized as a tutorial.

Ian

Re: GCC porting tutorials

[Bernd Roesch]

Hello 

On 24.04.10, you wrote:


> I don't know of a tutorial, but I want to make sure that you are
> looking at the internal docs: http://gcc.gnu.org/onlinedocs/gccint/ .
> They include the information you need for a new port, though not
> organized as a tutorial.

I know only Porting GCC for Dunces from Hans Peter-Nillson May 21. 2000
Its here

ftp://ftp.axis.se/pub/users/hp/pgccfd/pgccfd-0.5.pdf

It help me to understand GCC better, but i think this is now outdate, because of lots internal
changes.
maybe here can somebody update it.

> 
> Ian
Regards

Re: GCC porting tutorials

[Jonas Paulsson]

Hi,

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).

Even though I was aiming for a DSP architecture, I wrote down some things 
that concluded my experiences during the project. When setting out, I was 
completely new to GCC internals. I also found the Bombay links quite useful.

Good luck,

Jonas Paulsson
LTH, Sweden


----- Original Message ----- 
From: "Radu Hobincu" <radu.hobincu@arh.pub.ro>
To: <gcc@gcc.gnu.org>
Cc: "Vali Codreanu" <vali.codreanu@arh.pub.ro>; "Petronela Agache" 
<petronela.silvia@gmail.com>
Sent: Saturday, April 24, 2010 10:53 AM
Subject: GCC porting tutorials


> Hello,
>
> My name is Radu Hobincu, I am part of a team at "Politehnica" University
> of Bucharest that is developing a massive parallel computing architecture
> and currently my job is to port the GCC compiler to this new machine.
>
> I've been looking over the GCC official site at http://gcc.gnu.org/ but I
> couldn't find an official porting tutorial. Is there such a thing? And
> maybe a small example for a lightweight architecture?
>
> Regards,
> Radu 

Re: GCC porting tutorials

[Radu Hobincu]

Hello again and thank you a lot for the quick replies! I am impressed by
the number of mails I got in such a short time. You helped us loads.

I will also try to document our work every step of the way, maybe it will
help someone else in the future.

Regards,
Radu

Re: GCC porting tutorials

[Hans-Peter Nilsson]

> 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

Re: GCC porting tutorials

[Jonas Paulsson]

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
>

Widening multiplications (was: Re: GCC porting tutorials)

[Hans-Peter Nilsson]

> Date: Tue, 27 Apr 2010 20:41:47 +0200 (CEST)
> From: "Jonas Paulsson" <d03jp@student.lth.se>

> 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!

I'd be happy to help where I can, but I should say I'm not a
tree (gimple, SSA) aficionado.

As a first step, enter a bug report with actual C source (and
the emitted assembly code) showing the lack of widening
multiplication instructions (those [su]mulsi{di3|3_highpart}) in
a context where they should be emitted but aren't (in a loop),
and where they with a small modification are (loop removed).
Pick a familiar target with widening multiplications.  It should
come as no surprise that I'd choose CRIS v32 (at least v8), but
for example i386, MIPS and ARM have these instructions as well.
Bonus points if the code shows the general problem for more than
one architecture (shouldn't be a problem, and I think target
maintainers will chime in here).  Please do this for current
source trunk, but certainly okay if you do it *also* for a
branch or a release.

> The solution of handling this during expansion that I used, is not wrong
> the way I see it.

Then by all means, pursue.  I couldn't see any immediate errors.
The tree-people will most likely make themselves heard, not the
least if the solution is wrong.  Beware: you might not get a
clear go-ahead just on a high-level proposal.  Be prepared to
code and then rewrite if the suggested solution is judged to be
Not the Right Thing at the higher level.

By the way, this is a good time for getting the copyright
assignment paperwork done.  If you wait until code is written,
the paperwork might take long enough that you lose interest or
something else happens; it *can* take months.  Mention current
employment status to get the right papers.

brgds, H-P

Re: GCC porting tutorials

[Bernd Schmidt]

On 04/27/2010 08:41 PM, Jonas Paulsson wrote:

>> 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

Widening multiplies should work again after r158633 and 158643.  If
there are cases that still don't work for you, please file bugzilla PRs.


Bernd

Re: GCC porting tutorials

[Jonas Paulsson]

It feels good to know that the widening mults issue has been resolved as
it was a bit of a disapointment I noted the erratic behaviour with GCC
4.4.1. Perhaps you would care to comment on what to expect as a user now,
then?

Another issue that gave me porting problems was the SIMD memory accesses,
for e g doing a wide load into two adjacent narrow registers with one
instruction. This was resolved earlier on the mailinglist to not be
handleable on RTL, so I wonder now if anything has been done for this, as
it too seems rather reasonable, just like the widening loads?

/Jonas Paulsson




> On 04/27/2010 08:41 PM, Jonas Paulsson wrote:
>
>>> 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
>
> Widening multiplies should work again after r158633 and 158643.  If
> there are cases that still don't work for you, please file bugzilla PRs.
>
>
> Bernd
>
>

Parallelized loads and widening mults cont:ed (was: Re: GCC porting tutorials)

[Hans-Peter Nilsson]

> Date: Thu, 29 Apr 2010 08:55:56 +0200 (CEST)
> From: "Jonas Paulsson" <d03jp@student.lth.se>

> It feels good to know that the widening mults issue has been
> resolved

Yes, nice, and as late as last week too, though the patch was
from February.

> as
> it was a bit of a disapointment I noted the erratic behaviour with GCC
> 4.4.1. Perhaps you would care to comment on what to expect as a user now,
> then?

IIUC, it should Just Work.  No, I haven't checked.  Note that
the fix was somewhat along the lines of what you wrote in your
thesis IIUC; adding a specific pass to fix up separated
operations.  See
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274> and
<http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00643.html>.  BTW,
my observation was from the 4.3 era.  It's a regression, which
explains why I hadn't noticed it with the 3.x version I used
before that.  A pity it was deemed too invasive to fix for 4.5.

> Another issue that gave me porting problems was the SIMD memory accesses,
> for e g doing a wide load into two adjacent narrow registers with one
> instruction. This was resolved earlier on the mailinglist to not be
> handleable on RTL, so I wonder now if anything has been done for this, as
> it too seems rather reasonable, just like the widening loads?

You wanted to load adjacent data in a wider mode that was then
to be separately used in a mode half that size, but the
registers had to be adjacent too?  That's kind of the opposite
problem to what's usually needed!  If the use of the data was
actually for the obvious wider mode (SI or V2HI), you'd just
have to define the movsi or movv2hi pattern and it would be
used, but that unfortunately seems not applicable in any way.
I'm not sure that problem is of common interest I'm afraid, but
if it can be resolved with a target-specific pass, there'd be
reason to add a hook somewhat like
TARGET_MACHINE_DEPENDENT_REORG, but earlier.

But, did you check whether combine tried to match RTL that
looked somewhat like:

(parallel
 [(set (reg:HI 1) (mem:HI (plus:SI (reg:HI 3) (const_int 2))))
  (set (reg:HI 2) (mem:HI (plus:SI (reg:HI 3) (const_int 4))))])

I.e. a parallel with the two loads where the addresses were
adjacent?  From gdb you inspect the calls to try_combine (IIRC).
That insn could have been matched to a pattern like:

(define_insn "*load_wide"
 [(set (match_operand:HI 0 "register_operand" "=d0,d1,d2")
       (match_operand:HI 1 "reg_plus_const_memory_operand" "m"))
  (set (match_operand:HI 2 "register_operand" "=d1,d2,d3")
       (match_operand:HI 3 "reg_plus_const_memory_operand" "m"))]
 "rtx_equal_p (XEXP (operands[3], 0),
               plus_constant (XEXP (operands[1]), 2))"
 "load_wide %0,%1")

Just a WAG, there are reasons this would not match in the
general case (for one, you'd want to try to match the opposite
order too).  Don't pay too much attention to the exact matching
predicates, constraints and condition above.  The point is just
whether combine tried to generate and match a parallel with two
valid loads, given source where there was obvious opportunity
for it.

That insn *could* then be caught with a pattern which would,
through the right constraints coerce register allocation to make
the right choices for the (initially separete) registers.  In
the example above, four registers are assumed to be valid as
destination with the matching singleton constraints d0..d3.

brgds, H-P