Re: Need some help deciphering RTL output...

[Richard Earnshaw <rearnsha at arm dot com>]

scottb@corelcomputer.com said:
> I'm working on tracking down a code generation bug with the ARM gcc
> 2.8.1 and EGCS compilers.  testglib.c is a preprocessed file from the
> Gnome project, that the compiler generates bad assembler code for.  I
> get the following message from the assembler:

> testglib.s:6949: Error: Can not represent OFFSET_IMM relocation in
> this object file format (1)

> The problem is a local label .LC164 that is referenced, but never
> defined in the compiler output anywhere.  This label only appears in
> the rtl output in the .greg file after the reload phase, however, I
> think the real problem is in combine.

> The "C" code defines the following long long variable:

> __extension__ typdef unsigned long long         guint64; guint64
> gu64t1 = (__extension__  (0x1d636b02300a7aa7ULL));

> At line 869 in the "C" code it loads this value, ands it with the long
> long value 0xff and then shifts the result right by 56 bits.

> Combine seems to change from this RTL sequence:


> (insn 6848 6847 6849 (set (reg:DI 1447)
>         (const_int 255)) 174 {movdi} (nil)
>     (expr_list:REG_EQUAL (const_int 255)
>         (nil)))

> (insn 6849 6848 6854 (set (reg:DI 1446)
>         (and:DI (reg/v:DI 69)
>             (reg:DI 1447))) 69 {anddi3} (insn_list 6848 (nil))
>     (expr_list:REG_DEAD (reg:DI 1447)
>         (nil)))

> to the following:

> (insn 6849 6848 6854 (set (reg:DI 1446)
>         (zero_extend:DI (subreg:QI (reg/v:DI 69) 0))) 150
> {zero_extendqidi2} (nil)
>     (nil))

Sorry for the delay replying.  Up to my eye-balls as usual..

The problem isn't in combine, which is doing a perfectly valid 
transformation.  The problem is in the ARM specific constant-reloading 
pass which runs as part of the machine dependent reorganization pass right 
at the end, before the final assembly is emitted.  This pass contains too 
many assumptions, and the example you provide breaks another of them (in 
this case, the broken assumption is that a constant needing reloading will 
always be a simple mov insn).  I think I know how to rewrite the code, but 
need to give some thought to it and I'll let you know.

Richard.