Re: Reloading Problems and Memory Addressing

[Frank Riese <hippo at informatik dot uni-bremen dot de>]

On Monday 10 April 2006 19:48, you wrote:
> Can it at least add (small) immediates to registers?

Nope, sry. The only instructions that take other arguments than registers are 
the aforementioned LDL/LDH (load low/high), branch instructions (they take a 
memory address) and four bit operations which can mask, invert, set or delete 
a bit in a register.

> IIRC, the PDP-11 is famous for accepting complex addresses, i.e. quite the
> opposite of your target machine, which is so simple I would suggest you
> write it from scratch. Does it need to be more than
>

Yes, you're right. When I started writing this backend I didn't have much 
experience with it. I took the smallest backend I could find and tried to 
adjust it to me needs. The number of macros in the internals docs was a bit 
overwhelming at first and GCC kept segfaulting on me - something I'm 
definately not used to from GCC. So, I was happy when I had something working 
to start with. But now I think it would have been cleaner to start from 
scratch.

> #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL)     \
>       if (REG_P (X))                                  \
>               goto LABEL;

I tried that out today. I wasn't sure about the exact contexts in which this 
macro is used. It seems to work fine, though.

> Try to add -fdump-rtl-greg or -fdump-rtl-greg-details when compiling
> __muldi3(). This will generate a libgcc2.c.*.greg file which will say
> exactly which reloads insn 260 has and which one is failing.

I will try that ASAP. But I'm now having problems with GCC (gcc-cross, for the 
target machine) segfaulting again:

$ gcc function1.c

[...]
function1.c: In function 'main':
function1.c:10: internal compiler error: Segmentation fault

(gdb) bt
#0  0x0829028f in htab_find_slot (htab=0x5b52202c, element=0xbf805284, 
insert=INSERT) at ../../gcc-4.0.2/libiberty/hashtab.c:707
#1  0x08215dc4 in cgraph_node (decl=0xb7d1b2f4) 
at ../../gcc-4.0.2/gcc/cgraph.c:181
#2  0x082163b8 in cgraph_rtl_info (decl=0xb7d1b2f4) 
at ../../gcc-4.0.2/gcc/cgraph.c:526
#3  0x0820e937 in rest_of_clean_state () at ../../gcc-4.0.2/gcc/passes.c:1477
#4  0x0809fbed in execute_pass_list (pass=0x82ede20) 
at ../../gcc-4.0.2/gcc/tree-optimize.c:526
#5  0x0809fe53 in tree_rest_of_compilation (fndecl=0xb7d1b2f4) 
at ../../gcc-4.0.2/gcc/tree-optimize.c:661
#6  0x0805a816 in c_expand_body (fndecl=0xb7d1b2f4) 
at ../../gcc-4.0.2/gcc/c-decl.c:6611
#7  0x08217c65 in cgraph_expand_function (node=0xb7d1b57c) 
at ../../gcc-4.0.2/gcc/cgraphunit.c:835
#8  0x08217d55 in cgraph_assemble_pending_functions () 
at ../../gcc-4.0.2/gcc/cgraphunit.c:307
#9  0x082183f5 in cgraph_finalize_function (decl=0xb7d1b2f4, nested=0 '\0') 
at ../../gcc-4.0.2/gcc/cgraphunit.c:399
#10 0x0805abde in finish_function () at ../../gcc-4.0.2/gcc/c-decl.c:6580
#11 0x0804eb8e in yyparse () at c-parse.y:401
#12 0x0804f87b in c_parse_file () at c-parse.y:2936
#13 0x08081b0a in c_common_parse_file (set_yydebug=0) 
at ../../gcc-4.0.2/gcc/c-opts.c:1102
#14 0x081f62c0 in toplev_main (argc=3212857988, argv=0xbf805e34) 
at ../../gcc-4.0.2/gcc/toplev.c:1010
#15 0xb7dbaed0 in __libc_start_main () from /lib/tls/libc.so.6
#16 0x08049b71 in _start () at ../sysdeps/i386/elf/start.S:119

This is function1.c:
-------------------------------
1:  int foo (short i) {
2:         i = 100;
3:         return i+50;
4:  }
5:  
6:  int main() {
7:         int j = foo(10);
8:         j += 25;
9:         return j;
10: }
-------------------------------
>       
> 1) Does BP really have to be fixed? You are sufficiently desparate for
> registers than you'll not fix BP unless the hardware itself mandates this.

I thought it needs to be fixed if I want to set it aside as the frame pointer. 
I removed it from the fixed registers and recompiled, but I haven't had a 
closer look at the generated code yet. Can I do the same thing with SP?

>
> 2) GCC generally doesn't handle multi-word registers well. Even if you ask
> for a subreg, it will either load it all into registers or nothing at all.
> Richard Henderson posted a "multi-word subreg lowering" patch a while ago,
> which might help. See
> <URL:http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html>. The patch
> needs to be updated to work on current mainline, though.
>
> 3) Reload sometimes fritters away registers. DJ Delorie recently submitted
> a patch to allow chaining of reloads, which reduces the number of registers
> needed in some cases. This will only help you if you upgrade your code base
> to mainline, though.
>
> If you can, develop against mainline rather than an old version of GCC.
I will move to mainline and see if it helps. 

Thank you for your time and suggestions!

Cheers,
Frank