Contributing to GCC

[Jeff Law]

On 10/17/14 01:12, Krzesimir Nowak wrote:
> Hello.
>
> My name is Krzesimir Nowak and I'd like to try my hand at contributing
> to gcc in my free time.
>
> To start learning a workflow I started with something easy - 42014. Is
> testcase for this fix necessary (it would be checking preprocessor
> output)? Is sending a patch created by "git format-patch" for review
> with git-send-email to gcc-patches acceptable (or even better - git
> patches with cover letter)?
A project you could tackle would be furthering David's work on improving 
the typesafety of RTX objects.

In simplest terms, until recently all RTL objects were of type "rtx". 
We've started work to try and utilize more concrete objects, for example 
"rtx_insn *" for objects which are part of the INSN chain.  There's 
numerous benefits of this work and I'm happy to walk you through them if 
you want more details.


So one easy project would be to search for objects of type "rtx" that 
should be converted to type "rtx_insn *".  Commonly these variables will 
be called "insn" or "jump_insn".

Often you'll just need to fix the type.  In fact, I'd initially focus 
strictly on those.  In cases where the object you want to convert is a 
return value or argument to another function which hasn't been converted 
yet, you can:

  1. Punt and return to it later after more infrastructure is in place.

  2. Use checked casts to convert between rtx_insn * and rtx.

  3. Convert the target function.


#1 is the easiest, and would be my recommendation when you're just 
getting started.   You can always come back after you're more familiar 
with the codebase and know how to utilize #2 or #3.

#2 is still quite useful.  First we get the stronger typechecking, but 
the checked casts are also useful markers for folks who are working on 
the underlying infrastructure a converting function arguments/return 
values in #3.

#3 is by far the most useful, but may require quite a bit more work as 
the function in question may be used in many places, by backends, etc 
and converting everything at once may be nontrivial.  Finding a good 
"stop point" for a particular batch of work can be hard.  Just look at 
David's patchkit that had 239 parts that got the ball rolling.


You might start by looking at the backend code generators since there'll 
be fewer cases where you need to change the return type or an argument 
type for functions which are used across multiple backends.

I just happened to be converting the HPPA backend because I'm going to 
poke at the code generator for other reasons.  But there's dozens of 
other backends you could look to convert.  I'm attaching the 
work-in-progress on the PA backend so you can see a concrete example.

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pa.rtx.patch
Type: text/x-patch
Size: 6972 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20141029/81d17c21/attachment.bin>