Re: [patch] MIPS gas problems with gcc's explicit relocs

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On Thu, 3 Jun 2004, Thiemo Seufer wrote:

> > I just wanted to point out that using %lo(...) in "m" constraints
> > isn't in itself a new thing.  And that includes "m" constraints in
> > inline asms, since gcc doesn't treat them any differently from "m"
> > constraints in its own internal patterns.  For example, if you
> > select non-abicalls o32 or o64 code, I think it's been possible
> > for "m" to use %lo(...) for some time.  (Unless of course you
> > disabled it via -mno-split-addresses.)
> 
> For register-indexed memory load/stores this happens to work, but
> la/dla/li/dli are expanded to immediate loads. They use purely
> register operations, and need the "m" reference only for its address.
> 
> > If allowing %lo(...) in dla isn't acceptable (I've no opinion either
> > way really),
> 
> It's not about the %(lo) versus some constant or symbol.
> I think it's a misfeature of gas to allow
> 
> 	la <reg>, <const>(<reg2>)
> 
> which suggests the idea of having a memory load, but expands to
> 
> 	lui <reg>, %hi(<const>)
> 	addiu <reg>, %lo(<const>)
> 	addu <reg>, <reg>
> 
> while the usual load operations like
> 
> 	lw <reg>, <const>(<reg2>)
> 
> expand to some actual memory access
> 
> 	lui <reg>, %hi(<const>)
> 	lw <reg>, %lo(<const>)(<reg2>)
> 
> and while
> 
> 	li <reg>, <const>(<reg2>)
> 
> is rejected as invalid by the assembler. For gcc this problem probably
> never appears, but inline assembler code should either always get the
> full unprocessed argument, or we need different constraints for memory
> loads and memory addresses.

 Apparently others want to use it, too.  I can see it mentioned e.g. in:
"IDT R30xx Family Software Reference Manual" (revision 1.0, p. 9-6, IDT
doc #3467), where such expansions are quoted:

la	$2, 4($3)	->	addiu	$2, $3, 4

la	$2, addr	->	lui	$at, %hi_addr
				addiu   $2, $at, %lo_addr

la	$2, addr($3)	->	lui	$at, %hi_addr
				addiu	$2, $at, %lo_addr
				addu	$2, $2, $3

which I find consistent with my assumption addresses should be handled
uniformly universally.  The book was largely written by Dominic Sweetman
and Nigel Stephens, so perhaps they can express their opinions whether
using "la" for anything beyond symbol literals is broken or not.  I find
it a natural consequence of the macro being "load *address*" after all.

 The "li" macro naturally rejects any non-immediate addresses as it's
"load *immediate*".

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +