Re: Segmentation fault when compiling GCC with new RTL pass

[Tomasz Jankowski <tomcioj at gmail dot com>]

Hello again,

2012/10/3 Georg-Johann Lay <gjl@gcc.gnu.org>:
> Tomasz Jankowski schrieb:
>
> Are you adding a pattern/singe_set to the insn stream?
> You need an insn.
>

Yes, this was the reason, I was using rtx with patten instead of valid
insn. After reading more source code I found, that I have to use
make_insn_raw() to create insn from patter. This problem is solved,
however I face new issues:

*** 1. ***
When reading source code of RTL passes I saw two ways of browsing
insn. In one way basic blocks are used, in the way we have something
like:

    FOR_EACH_BB(bb)
    {
        FOR_BB_INSNS(bb, insn)
        {
             // do something with insn
        }
    }

and in the second way we access insns using "get_insns()" function
from rtl.h and just handle it in regular "for" loop. What's the
difference between these two solutions? When using basic blocks we
browse source code as function by function. But when we use
"get_insns()" we simple go trough all insns in current compilation
unit, right?

*** 2. ***
What's the difference between "emit_insn_...()" and "add_insn_...()"
functions? From RTL pass point of view, they seem to work in the same
way.

*** 3. ***
In OpenRISC assigning 32 bit constant to register is handled by
"define_expand". What I want to do is to call my instruction after
constant is copied to register. For such assignment in C:

    int AAAA = 12345678;

I get such dump after RTL expand:

    (insn 5 4 6 3 simple_test.c:3 (set (reg:SI 43)
            (const_int 12320768 [0xbc0000])) -1 (nil))

Then my new pass is executed and I get ("rto" is my custom instruction
and it take single register):

    (insn 5 4 19 3 simple_test.c:3 (set (reg:SI 43)
            (const_int 12320768 [0xbc0000])) -1 (nil))
    (insn 19 5 6 3 (rto:SI (reg:SI 43)) -1 (nil))

At this point everything is ok, but in final assembler output, here
this assignment is expanded with "define_expand" I get:

    l.movhi 	r3,hi(12320768)	 # move immediate M
    l.rto	r3
    l.ori   	r3,r3,24910

instead of:

    l.movhi 	r3,hi(12320768)	 # move immediate M
    l.ori   	r3,r3,24910
    l.rto	r3

I don't know why mu instruction call gets "injected" in the previous
define_expand output.



I also want to mention that I'm extending GCC for my BSc of Computer
Science thesis. All your answers will not get lost in this mailing
list, because I'm going to write some sort of tutorial of extending
GCC with new RTL and GIMPLE passes.

Last thing - should I send my questions on gcc-help or other mailing list?