Re: [COMMIT] romcc 0.63 and some fixes...

[YhLu]

Eric,

The 
printo_debug("this mainboard is only designed for 2 cpus\r\n");

causes the segment dump.

Another problem. After only change print_debug in raminit.c, the final image
size get bigger from 68663 to 70203.

Regards

YH

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 
发送时间: 2004年6月3日 1:31
收件人: YhLu
抄送: LinuxBIOS
主题: Re: 答复: 答复: 答复: [COMMIT] romcc 0.63 and some fixes...

YhLu  writes:
> Eric,
> I add in console.c
> static void printo_debug(const char *str) __attribute__((noinline))
> {
>    print_debug(str);
> }
>
> About only chang print_debug in auto.c
>
> It said
> ./romcc -O2 -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
> make[1]: *** [auto.inc] Segmentation fault
>
> ./romcc -O -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
> make[1]: *** [auto.inc] Segmentation fault

Cool, my first bug report.  I knew I had touched to much code
for the new release to run without a hitch.

Could you look at the core dump with gdb and give me a back trace?
That should help even if I can't reproduce the problem on this end.

Eric

[COMMIT] romcc 0.63 and some fixes...

YhLu  writes:
> Eric,
>
> The 
> printo_debug("this mainboard is only designed for 2 cpus\r\n");
>
> causes the segment dump.

A update on this...

I took some time and tracked the problem down.  So far
I have exposed 2 problems in romcc with your code.

The first that was causing the core dump I have fixed.

The second is a little more insidious.  Basically
when call/return instructions are introduced the control
flow graph is no longer a graph.  Because the structure
changes depending on which path you take through the code.

What happens currently is I treat it like a graph and get
a conservative estimate on the control flow structure.  So no
incorrect transformations happen to the code.  However there are a
number of cases and your code was one where code that is correct
does not appear to be.  Because it appears that there are additional
paths to a basic block, when there are not.

The result is some legitimate cases will not compile.  And likely
that some optimization opportunities are lost.  I suspect the lost
optimization opportunities are responsible for the code size growth.

Without calls and returns the dominance relationship between
instructions is transitive. Instruction X dominates instruction Y if
you must execute X before Y.  With call/return pairs the dominance
relationship is no longer quite transitive which is going to take
some delicate manipulation to let romcc understand this without
breaking it.

I am going to spend a little more time looking at this and when I am
done I am going to commit however many fixes/enhancements that I have.

Eric