Re: porting GCC

[Richard Earnshaw <rearnsha at arm dot com>]

> ----- Original Message -----
> From: "Richard Earnshaw" <rearnsha@arm.com>
> Sent: Friday, February 02, 2001 13:00
> 
> 
> > > I am generating several insn-s inside define_expand. The meaning of the
> code
> > > is not exactly the same, as the rtl matched. The problem is that GCC
> always
> > > notes the last insn I generate with REG_EQUAL expression, corresponding
> to
> > > the ORIGINAL code... I don't know how to avoid this...
> >
> > Why is this a problem?  Gcc annotates the end of the sequence with a note
> > of the equivalent it collapses to.  If you think of (symbol_ref
> > ("__clz_tab")) as the final address that will be dereferenced then the
> > expression
> >
> > (unspec [(symbol_ref ("__clz_tab"))] 3)
> > should be thought of as being equivalent to
> >
> > (minus (symbol_ref ("__clz_tab")) (reg:SI base_reg))
> 
> I'm not sure if I understand this... Maybe there's something wrong that GCC
> thinks of (symbol_ref ("__clz_tab")) as absolute address and the assembly
> instructions not:
> 
>      (expr_list:REG_EQUAL (plus:SI (mem:SI (reg:SI 9))
>              (symbol_ref/v:SI ("__clz_tab")))
> 
> (reg:SI 9) here represents the index to the __clz_tab, not the segment
> base...
> Referencing an element requires addition of segment base ((reg:SI 14) in the
> example below), the index (reg:SI 9) and the relative starting offset of the
> array: (symbol_ref/v:SI ("__clz_tab")). When I write the __clz_tab reference
> into otput file I get the offset only...

Try to think of it from a different perspective...

Let (symbol_ref/v:SI ("__clz_tab")) be the ABSOLUTE address in memory 
where the information will finally reside (forget that the symbol you 
eventually write to the assembly will be called __clz_tab).

Given the above
  (symbol_ref ("__clz_tab")) = (plus:SI (base_reg) (XXX))

where XXX is some other expression.  So by basic algebra

  (XXX) = (minus:SI (symbol_ref ("__clz_tab")) (base_reg))

However, if we put this expression directly in the RTL, gcc would get 
confused and try to optimize it away.  to prevent this we represent the 
expression with the unspec sequence

  (unspec:SI [(symbol_ref ("__clz_tab"))] 3)

And when we finally come to write out the assembly code, we simply use the 
name "__clz_tab" there, since the assembler knows that this is an offset 
from some implied segment register.


> The segment base is not a single register. It is always accessible as first
> hidden argument to every function. It always needs to execute code to get it
> into register... I don't think I can do this inside define_insn...
> 
> When I compile my example with -O2 GCC makes use of the REG_EQUAL and
> produces rlt that doesn't match any insn (and in fact is incorrect):
> 
> (insn 10 8 11 (set (reg:SI 15)
>         (plus:SI (reg/v:SI 13)
>             (symbol_ref/v:SI ("__clz_tab")))) -1 (nil)
>     (nil))
> 
> (reg/v:SI 13) stands here for the index to the array. No segment base
> addition takes place.

This is because you have some rule elsewhere in your machine description 
that says that such a statement is valid.  Does LEGITIMATE_CONSTANT allow 
symbol_ref?  In your machine description an unwrapped symbol_ref must 
never be allowed anywhere or you will run into problems of this nature.