ill effect of <register>+<constant>

ill effect of <register>+<constant>

[Jan Beulich]

Isn't it a bug that, for i386,

.text
.intel_syntax noprefix
_start:
.equ base, edx+4
.equ idx, edi-1
	mov	eax, [base+idx*4]

results in

	mov	eax, [esi+esi*4]

? Consequently, shouldn't expr() refrain from doing *any* optimization when
either side of O_add or the left side of O_subtract is a register? There are two
intentions I have with using expr() rather than doing parsing by hand (one is
the parsing of register names in the .cfi_* directive handling, the other is the
handling of x86 Intel mode (instruction operand) expressions, but both would
depend on register symbols to be retained unchanged throughout the
expression parsing/evaluation.

Thanks, Jan

Re: ill effect of <register>+<constant>

[Andreas Schwab]

"Jan Beulich" <jbeulich@novell.com> writes:

> Isn't it a bug that, for i386,
>
> .text
> .intel_syntax noprefix
> _start:
> .equ base, edx+4
> .equ idx, edi-1
> 	mov	eax, [base+idx*4]
>
> results in
>
> 	mov	eax, [esi+esi*4]
>
> ? Consequently, shouldn't expr() refrain from doing *any* optimization when
> either side of O_add or the left side of O_subtract is a register?

No, that would disable a useful feature.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ill effect of <register>+<constant>

[Jan Beulich]

>>> Andreas Schwab <schwab@suse.de> 21.09.07 16:06 >>>
>"Jan Beulich" <jbeulich@novell.com> writes:
>
>> Isn't it a bug that, for i386,
>>
>> .text
>> .intel_syntax noprefix
>> _start:
>> .equ base, edx+4
>> .equ idx, edi-1
>> 	mov	eax, [base+idx*4]
>>
>> results in
>>
>> 	mov	eax, [esi+esi*4]
>>
>> ? Consequently, shouldn't expr() refrain from doing *any* optimization when
>> either side of O_add or the left side of O_subtract is a register?
>
>No, that would disable a useful feature.

To me, adding a constant to a register and getting a different register is
all but a useful feature (maybe it is in e.g. PPC semantics where registers
can be represented by plain numbers). But beyond that, I can't see what
useful feature you're thinking about - could you be a little more verbose?

Thanks, Jan

Re: ill effect of <register>+<constant>

[Andreas Schwab]

"Jan Beulich" <jbeulich@novell.com> writes:

> To me, adding a constant to a register and getting a different register is
> all but a useful feature (maybe it is in e.g. PPC semantics where registers
> can be represented by plain numbers). But beyond that,

That's the main feature.  Registers _are_ plain numbers.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ill effect of <register>+<constant>

[Jan Beulich]

>>> Andreas Schwab <schwab@suse.de> 21.09.07 17:13 >>>
>"Jan Beulich" <jbeulich@novell.com> writes:
>
>> To me, adding a constant to a register and getting a different register is
>> all but a useful feature (maybe it is in e.g. PPC semantics where registers
>> can be represented by plain numbers). But beyond that,
>
>That's the main feature.  Registers _are_ plain numbers.

... on some architectures. On others, they aren't (if they were, there wouldn't
be any sense in having special O_register and reg_section values).

Jan

RE: ill effect of <register>+<constant>

[Dave Korn]

On 21 September 2007 16:13, Andreas Schwab wrote:

> "Jan Beulich" <jbeulich@novell.com> writes:
> 
>> To me, adding a constant to a register and getting a different register is
>> all but a useful feature (maybe it is in e.g. PPC semantics where registers
>> can be represented by plain numbers). But beyond that,
> 
> That's the main feature.  Registers _are_ plain numbers.

  I can see where that's useful on pcc, but on x86, the registers aren't
equipotent; it makes no sense at all to me.

  Do you have an example which actually arises in practice where this is
useful?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: ill effect of <register>+<constant>

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

> On 21 September 2007 16:13, Andreas Schwab wrote:
>
>> "Jan Beulich" <jbeulich@novell.com> writes:
>> 
>>> To me, adding a constant to a register and getting a different register is
>>> all but a useful feature (maybe it is in e.g. PPC semantics where registers
>>> can be represented by plain numbers). But beyond that,
>> 
>> That's the main feature.  Registers _are_ plain numbers.
>
>   I can see where that's useful on pcc, but on x86, the registers aren't
> equipotent; it makes no sense at all to me.

But it does no harm either.  So why cripple the assembler?  If you want
text replacement then use a text macro.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: ill effect of <register>+<constant>

[Dave Korn]

On 21 September 2007 17:21, Andreas Schwab wrote:

> "Dave Korn" <dave.korn@artimi.com> writes:
> 
>> On 21 September 2007 16:13, Andreas Schwab wrote:
>> 
>>> "Jan Beulich" <jbeulich@novell.com> writes:
>>> 
>>>> To me, adding a constant to a register and getting a different register
>>>> is all but a useful feature (maybe it is in e.g. PPC semantics where
>>>> registers can be represented by plain numbers). But beyond that,
>>> 
>>> That's the main feature.  Registers _are_ plain numbers.
>> 
>>   I can see where that's useful on pcc, but on x86, the registers aren't
>> equipotent; it makes no sense at all to me.
> 
> But it does no harm either.  

  Well, to me, turning an instruction that refers to edi and edx into one that
references esi is somewhat in accord with the principle of *most* surprise!

> So why cripple the assembler?  

  I don't see how removing an unused and non-useful feature would really count
as "crippling".  I'm not suggesting it should be disabled for ppc, but for
x86, really .... what could conceivably be the use?

> If you want text replacement then use a text macro.

  Yeh, that's a reasonable argument.  I think what I want most of all would be
for it to fold

  mov eax,[base+idx*4] 
    -> mov eax,[edx+4+(edi-1)*4] 
        -> mov eax,[edx+4+edi*4-1*4]
            -> mov eax,[edx+edi*4]

but I guess that's a different story altogether.

  Perhaps in this case the assembler could issue a warning that "Adding
integers to registers may not do what you expect"?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: ill effect of <register>+<constant>

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

>   I don't see how removing an unused and non-useful feature would really count
> as "crippling".  I'm not suggesting it should be disabled for ppc, but for
> x86, really .... what could conceivably be the use?

There are many more architectures besides ppc and x86.  Almost all of
them have numbered registers.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: ill effect of <register>+<constant>

[Dave Korn]

On 21 September 2007 18:31, Andreas Schwab wrote:

> "Dave Korn" <dave.korn@artimi.com> writes:
> 
>>   I don't see how removing an unused and non-useful feature would really
>> count as "crippling".  I'm not suggesting it should be disabled for ppc,
>> but for x86, really .... what could conceivably be the use?
> 
> There are many more architectures besides ppc and x86.  Almost all of
> them have numbered registers.

  Are you deliberately missing the point on purpose for rhetorical purposes?
I'm not suggesting it makes no sense for any architecture *except* x86.  I
hope that is clearer.  It certainly does make sense for anything with a big
set of idempotent numbered registers.

  But really, please: what's the use of being able to turn (for example) cx
into edi by adding a number to it?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: ill effect of <register>+<constant>

[Paul Koning]

>>>>> "Andreas" == Andreas Schwab <schwab@suse.de> writes:

 Andreas> "Dave Korn" <dave.korn@artimi.com> writes:
 >> I don't see how removing an unused and non-useful feature would
 >> really count as "crippling".  I'm not suggesting it should be
 >> disabled for ppc, but for x86, really .... what could conceivably
 >> be the use?

 Andreas> There are many more architectures besides ppc and x86.
 Andreas> Almost all of them have numbered registers.

Sure.  The question is: on how many of those do good programmers ever
do register number arithmetic?

I know of none.  I would not want to work with a programmer who did
such a thing.

     paul

Re: ill effect of <register>+<constant>

[Michael Hennebry]

On Fri, 21 Sep 2007, Paul Koning wrote:

> Sure.  The question is: on how many of those do good programmers ever
> do register number arithmetic?
>
> I know of none.  I would not want to work with a programmer who did
> such a thing.

What about registers used in pairs,
either by the hardware or by an ABI?
Perhaps a macro to fill both halves of an
AVR's 17:16, 19:80, ... or 31:30 register?

-- 
Mike   hennebry@web.cs.ndsu.NoDak.edu
"Horse guts never lie."  -- Cherek Bear-Shoulders

Re: ill effect of <register>+<constant>

[Andreas Schwab]

Paul Koning <pkoning@equallogic.com> writes:

>>>>>> "Andreas" == Andreas Schwab <schwab@suse.de> writes:
>
>  Andreas> "Dave Korn" <dave.korn@artimi.com> writes:
>  >> I don't see how removing an unused and non-useful feature would
>  >> really count as "crippling".  I'm not suggesting it should be
>  >> disabled for ppc, but for x86, really .... what could conceivably
>  >> be the use?
>
>  Andreas> There are many more architectures besides ppc and x86.
>  Andreas> Almost all of them have numbered registers.
>
> Sure.  The question is: on how many of those do good programmers ever
> do register number arithmetic?
>
> I know of none.  I would not want to work with a programmer who did
> such a thing.

What's wrong with using the registers as a (small) array?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ill effect of <register>+<constant>

[Erik Christiansen]

On Fri, Sep 21, 2007 at 02:19:43PM -0400, Paul Koning wrote:
> >>>>> "Andreas" == Andreas Schwab <schwab@suse.de> writes:
> 
>  Andreas> "Dave Korn" <dave.korn@artimi.com> writes:
>  >> I don't see how removing an unused and non-useful feature would
>  >> really count as "crippling".  I'm not suggesting it should be
>  >> disabled for ppc, but for x86, really .... what could conceivably
>  >> be the use?
> 
>  Andreas> There are many more architectures besides ppc and x86.
>  Andreas> Almost all of them have numbered registers.
> 
> Sure.  The question is: on how many of those do good programmers ever
> do register number arithmetic?
> 
> I know of none.  I would not want to work with a programmer who did
> such a thing.

The following "good programming" macro for AVR employs this absolutely
essential feature. The address loading is much like PPC's lis & ori, but
here the pointer comprises two registers, necessitating register address
arithmetic.

; Program Pointer initialisation of a register pair.
; Usage: pptr  Z,program_address
;        icall
   
   .macro pptr reg, addr   
   ldi   \reg, pm_lo8(\addr)       ; Does byte_address/2,
   ldi   \reg + 1, pm_hi8(\addr)   ; for use with icall.
   .endm 

Setting up a 32 bit operand in 4 successive ABI registers would be
another simple case.

The result of such arithmetic is predictable. If the result doesn't
please, then add a different constant? (Now it's probably my turn to not
quite sync with the other perspective? :-)

Erik

Re: ill effect of <register>+<constant>

[Jan Beulich]

>>> Andreas Schwab <schwab@suse.de> 21.09.07 18:21 >>>
>"Dave Korn" <dave.korn@artimi.com> writes:
>
>> On 21 September 2007 16:13, Andreas Schwab wrote:
>>
>>> "Jan Beulich" <jbeulich@novell.com> writes:
>>> 
>>>> To me, adding a constant to a register and getting a different register is
>>>> all but a useful feature (maybe it is in e.g. PPC semantics where registers
>>>> can be represented by plain numbers). But beyond that,
>>> 
>>> That's the main feature.  Registers _are_ plain numbers.
>>
>>   I can see where that's useful on pcc, but on x86, the registers aren't
>> equipotent; it makes no sense at all to me.
>
>But it does no harm either.  So why cripple the assembler?  If you want
>text replacement then use a text macro.

What are text macros? I didn't think gas knew of this concept (which e.g. masm
supports). The only way I could imagine this to work would be to use CPP, but
you can't really make CPP use a requirement (specifically because there are
things you can't express or which look very wrong with CPP that you can with
.macro).

Jan

Re: ill effect of <register>+<constant>

[Jan Beulich]

>>> Andreas Schwab <schwab@suse.de> 21.09.07 19:30 >>>
>"Dave Korn" <dave.korn@artimi.com> writes:
>
>>   I don't see how removing an unused and non-useful feature would really count
>> as "crippling".  I'm not suggesting it should be disabled for ppc, but for
>> x86, really .... what could conceivably be the use?
>
>There are many more architectures besides ppc and x86.  Almost all of
>them have numbered registers.

... including (what I would call broken) side effects like being able to use register
names that don't fit the instruction they're used with or the inability to deduce
the originally intended register from its number (e.g. when using equates of
registers in .cfi_* directives, which is currently really broken and which I
indicated I want to get fixed [at least for those architectures that permit fixing,
i.e. those where I *can* deduce the register from the GAS register number
and hence translate it to a proper Dwarf2 one]).

Jan

[PATCH] RE: ill effect of <register>+<constant>

[Jan Beulich]

>>> "Dave Korn" <dave.korn@artimi.com> 21.09.07 20:12 >>>
>On 21 September 2007 18:31, Andreas Schwab wrote:
>
>> "Dave Korn" <dave.korn@artimi.com> writes:
>> 
>>>   I don't see how removing an unused and non-useful feature would really
>>> count as "crippling".  I'm not suggesting it should be disabled for ppc,
>>> but for x86, really .... what could conceivably be the use?
>> 
>> There are many more architectures besides ppc and x86.  Almost all of
>> them have numbered registers.
>
>  Are you deliberately missing the point on purpose for rhetorical purposes?
>I'm not suggesting it makes no sense for any architecture *except* x86.  I
>hope that is clearer.  It certainly does make sense for anything with a big
>set of idempotent numbered registers.
>
>  But really, please: what's the use of being able to turn (for example) cx
>into edi by adding a number to it?

Here's a patch that disables such for x86 and ia64. Perhaps a few other
architecture may want to follow.

Built and tested on x86_64-unknown-linux-gnu and ia64-unknown-linux-gnu.

gas/
2007-09-25  Jan Beulich  <jbeulich@novell.com>

	* config/tc-i386.h (md_register_arithmetic): Define.
	* config/tc-ia64.h (md_register_arithmetic): Likewise.
	* expr.c (make_expr_symbol): Force O_register expressions into
	reg_section.
	(expr): Provide default for md_register_arithmetic. Don't resolve
	adding/subtracting constants to/from registers if
	md_register_arithmetic is zero.

--- 2007-09-25/gas/config/tc-i386.h	2007-09-25 16:27:43.000000000 +0200
+++ 2007-09-25/gas/config/tc-i386.h	2007-09-24 13:44:49.000000000 +0200
@@ -272,6 +272,8 @@ extern int tc_i386_fix_adjustable (struc
 extern int i386_parse_name (char *, expressionS *, char *);
 #define md_parse_name(s, e, m, c) i386_parse_name (s, e, c)
 
+#define md_register_arithmetic 0
+
 extern const struct relax_type md_relax_table[];
 #define TC_GENERIC_RELAX_TABLE md_relax_table
 
--- 2007-09-25/gas/config/tc-ia64.h	2007-08-22 11:01:53.000000000 +0200
+++ 2007-09-25/gas/config/tc-ia64.h	2007-09-24 11:23:34.000000000 +0200
@@ -130,6 +130,7 @@ extern void ia64_convert_frag (fragS *);
 #endif /* TE_HPUX */
 #define md_flush_pending_output()	ia64_flush_pending_output ()
 #define md_parse_name(s,e,m,c)		ia64_parse_name (s, e, c)
+#define md_register_arithmetic		0
 #define tc_canonicalize_symbol_name(s)	ia64_canonicalize_symbol_name (s)
 #define tc_canonicalize_section_name(s)	ia64_canonicalize_symbol_name (s)
 #define md_optimize_expr(l,o,r)		ia64_optimize_expr (l, o, r)
--- 2007-09-25/gas/expr.c	2007-08-22 11:01:50.000000000 +0200
+++ 2007-09-25/gas/expr.c	2007-09-24 11:21:31.000000000 +0200
@@ -95,7 +95,9 @@ make_expr_symbol (expressionS *expressio
   symbolP = symbol_create (FAKE_LABEL_NAME,
 			   (expressionP->X_op == O_constant
 			    ? absolute_section
-			    : expr_section),
+			    : expressionP->X_op == O_register
+			      ? reg_section
+			      : expr_section),
 			   0, &zero_address_frag);
   symbol_set_value_expression (symbolP, expressionP);
 
@@ -1722,7 +1724,11 @@ expr (int rankarg,		/* Larger # is highe
 	}
       else
 #endif
-      if (op_left == O_add && right.X_op == O_constant)
+#ifndef md_register_arithmetic
+# define md_register_arithmetic 1
+#endif
+      if (op_left == O_add && right.X_op == O_constant
+	  && (md_register_arithmetic || resultP->X_op != O_register))
 	{
 	  /* X + constant.  */
 	  resultP->X_add_number += right.X_add_number;
@@ -1745,12 +1751,14 @@ expr (int rankarg,		/* Larger # is highe
 	  resultP->X_op = O_constant;
 	  resultP->X_add_symbol = 0;
 	}
-      else if (op_left == O_subtract && right.X_op == O_constant)
+      else if (op_left == O_subtract && right.X_op == O_constant
+	       && (md_register_arithmetic || resultP->X_op != O_register))
 	{
 	  /* X - constant.  */
 	  resultP->X_add_number -= right.X_add_number;
 	}
-      else if (op_left == O_add && resultP->X_op == O_constant)
+      else if (op_left == O_add && resultP->X_op == O_constant
+	       && (md_register_arithmetic || right.X_op != O_register))
 	{
 	  /* Constant + X.  */
 	  resultP->X_op = right.X_op;

Re: [PATCH] RE: ill effect of <register>+<constant>

[Jakub Jelinek]

On Tue, Sep 25, 2007 at 05:03:12PM +0100, Jan Beulich wrote:
> >>> "Dave Korn" <dave.korn@artimi.com> 21.09.07 20:12 >>>
> >On 21 September 2007 18:31, Andreas Schwab wrote:
> >
> >> "Dave Korn" <dave.korn@artimi.com> writes:
> >> 
> >>>   I don't see how removing an unused and non-useful feature would really
> >>> count as "crippling".  I'm not suggesting it should be disabled for ppc,
> >>> but for x86, really .... what could conceivably be the use?
> >> 
> >> There are many more architectures besides ppc and x86.  Almost all of
> >> them have numbered registers.
> >
> >  Are you deliberately missing the point on purpose for rhetorical purposes?
> >I'm not suggesting it makes no sense for any architecture *except* x86.  I
> >hope that is clearer.  It certainly does make sense for anything with a big
> >set of idempotent numbered registers.
> >
> >  But really, please: what's the use of being able to turn (for example) cx
> >into edi by adding a number to it?
> 
> Here's a patch that disables such for x86 and ia64. Perhaps a few other
> architecture may want to follow.

Except that x86_64 has numbered registers as well, r8-r15.

	Jakub

Re: [PATCH] RE: ill effect of <register>+<constant>

[Nick Clifton]

Hi Jan,

> Here's a patch that disables such for x86 and ia64. Perhaps a few other
> architecture may want to follow.

I think that the patch ought to include some documentation on this new md_ 
define.  In gas/doc/internals.texi presumably.

Cheers
   Nick

Re: [PATCH] RE: ill effect of <register>+<constant>

[H.J. Lu]

On Tue, Sep 25, 2007 at 06:28:03PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 25, 2007 at 05:03:12PM +0100, Jan Beulich wrote:
> > >>> "Dave Korn" <dave.korn@artimi.com> 21.09.07 20:12 >>>
> > >On 21 September 2007 18:31, Andreas Schwab wrote:
> > >
> > >> "Dave Korn" <dave.korn@artimi.com> writes:
> > >> 
> > >>>   I don't see how removing an unused and non-useful feature would really
> > >>> count as "crippling".  I'm not suggesting it should be disabled for ppc,
> > >>> but for x86, really .... what could conceivably be the use?
> > >> 
> > >> There are many more architectures besides ppc and x86.  Almost all of
> > >> them have numbered registers.
> > >
> > >  Are you deliberately missing the point on purpose for rhetorical purposes?
> > >I'm not suggesting it makes no sense for any architecture *except* x86.  I
> > >hope that is clearer.  It certainly does make sense for anything with a big
> > >set of idempotent numbered registers.
> > >
> > >  But really, please: what's the use of being able to turn (for example) cx
> > >into edi by adding a number to it?
> > 
> > Here's a patch that disables such for x86 and ia64. Perhaps a few other
> > architecture may want to follow.
> 
> Except that x86_64 has numbered registers as well, r8-r15.
> 

Registers in ia64 are also numbered.


H.J.

Re: [PATCH] RE: ill effect of <register>+<constant>

[Jan Beulich]

>>> Jakub Jelinek <jakub@redhat.com> 25.09.07 18:28 >>>
>On Tue, Sep 25, 2007 at 05:03:12PM +0100, Jan Beulich wrote:
>> >>> "Dave Korn" <dave.korn@artimi.com> 21.09.07 20:12 >>>
>> >On 21 September 2007 18:31, Andreas Schwab wrote:
>> >
>> >> "Dave Korn" <dave.korn@artimi.com> writes:
>> >> 
>> >>>   I don't see how removing an unused and non-useful feature would really
>> >>> count as "crippling".  I'm not suggesting it should be disabled for ppc,
>> >>> but for x86, really .... what could conceivably be the use?
>> >> 
>> >> There are many more architectures besides ppc and x86.  Almost all of
>> >> them have numbered registers.
>> >
>> >  Are you deliberately missing the point on purpose for rhetorical purposes?
>> >I'm not suggesting it makes no sense for any architecture *except* x86.  I
>> >hope that is clearer.  It certainly does make sense for anything with a big
>> >set of idempotent numbered registers.
>> >
>> >  But really, please: what's the use of being able to turn (for example) cx
>> >into edi by adding a number to it?
>> 
>> Here's a patch that disables such for x86 and ia64. Perhaps a few other
>> architecture may want to follow.
>
>Except that x86_64 has numbered registers as well, r8-r15.

But r8+1 doesn't mean r9 in any context. And you could have said the same
for ia64 (with the same reply by me).

Jan

Re: [PATCH] RE: ill effect of <register>+<constant>

[Jan Beulich]

>>> Nick Clifton <nickc@redhat.com> 25.09.07 18:21 >>>
>> Here's a patch that disables such for x86 and ia64. Perhaps a few other
>> architecture may want to follow.
>
>I think that the patch ought to include some documentation on this new md_ 
>define.  In gas/doc/internals.texi presumably.

Sorry, I keep forgetting about doing this. OK this way?

gas/
2007-09-26  Jan Beulich  <jbeulich@novell.com>

	* config/tc-i386.h (md_register_arithmetic): Define.
	* config/tc-ia64.h (md_register_arithmetic): Likewise.
	* doc/internals.texi: Document md_register_arithmetic.
	* expr.c (make_expr_symbol): Force O_register expressions into
	reg_section.
	(expr): Provide default for md_register_arithmetic. Don't resolve
	adding/subtracting constants to/from registers if
	md_register_arithmetic is zero.

--- 2007-09-25/gas/config/tc-i386.h	2007-09-25 16:27:43.000000000 +0200
+++ 2007-09-25/gas/config/tc-i386.h	2007-09-24 13:44:49.000000000 +0200
@@ -272,6 +272,8 @@ extern int tc_i386_fix_adjustable (struc
 extern int i386_parse_name (char *, expressionS *, char *);
 #define md_parse_name(s, e, m, c) i386_parse_name (s, e, c)
 
+#define md_register_arithmetic 0
+
 extern const struct relax_type md_relax_table[];
 #define TC_GENERIC_RELAX_TABLE md_relax_table
 
--- 2007-09-25/gas/config/tc-ia64.h	2007-08-22 11:01:53.000000000 +0200
+++ 2007-09-25/gas/config/tc-ia64.h	2007-09-24 11:23:34.000000000 +0200
@@ -130,6 +130,7 @@ extern void ia64_convert_frag (fragS *);
 #endif /* TE_HPUX */
 #define md_flush_pending_output()	ia64_flush_pending_output ()
 #define md_parse_name(s,e,m,c)		ia64_parse_name (s, e, c)
+#define md_register_arithmetic		0
 #define tc_canonicalize_symbol_name(s)	ia64_canonicalize_symbol_name (s)
 #define tc_canonicalize_section_name(s)	ia64_canonicalize_symbol_name (s)
 #define md_optimize_expr(l,o,r)		ia64_optimize_expr (l, o, r)
--- 2007-09-25/gas/doc/internals.texi	2007-02-05 10:14:37.000000000 +0100
+++ 2007-09-25/gas/doc/internals.texi	2007-09-26 09:09:30.000000000 +0200
@@ -1045,6 +1045,12 @@ pointer, for any expression that can not
 is called, @code{input_line_pointer} will point to the start of the
 expression.
 
+@item md_register_arithmetic
+@cindex md_register_arithmetic
+If this macro is defined and evaluates to non-zero, GAS will avoid folding
+expressions like adding a constant to a register into a register with its
+number being the sum of the original register's and the constant.
+
 @item tc_unrecognized_line
 @cindex tc_unrecognized_line
 If you define this macro, GAS will call it when it finds a line that it can not
--- 2007-09-25/gas/expr.c	2007-08-22 11:01:50.000000000 +0200
+++ 2007-09-25/gas/expr.c	2007-09-24 11:21:31.000000000 +0200
@@ -95,7 +95,9 @@ make_expr_symbol (expressionS *expressio
   symbolP = symbol_create (FAKE_LABEL_NAME,
 			   (expressionP->X_op == O_constant
 			    ? absolute_section
-			    : expr_section),
+			    : expressionP->X_op == O_register
+			      ? reg_section
+			      : expr_section),
 			   0, &zero_address_frag);
   symbol_set_value_expression (symbolP, expressionP);
 
@@ -1722,7 +1724,11 @@ expr (int rankarg,		/* Larger # is highe
 	}
       else
 #endif
-      if (op_left == O_add && right.X_op == O_constant)
+#ifndef md_register_arithmetic
+# define md_register_arithmetic 1
+#endif
+      if (op_left == O_add && right.X_op == O_constant
+	  && (md_register_arithmetic || resultP->X_op != O_register))
 	{
 	  /* X + constant.  */
 	  resultP->X_add_number += right.X_add_number;
@@ -1745,12 +1751,14 @@ expr (int rankarg,		/* Larger # is highe
 	  resultP->X_op = O_constant;
 	  resultP->X_add_symbol = 0;
 	}
-      else if (op_left == O_subtract && right.X_op == O_constant)
+      else if (op_left == O_subtract && right.X_op == O_constant
+	       && (md_register_arithmetic || resultP->X_op != O_register))
 	{
 	  /* X - constant.  */
 	  resultP->X_add_number -= right.X_add_number;
 	}
-      else if (op_left == O_add && resultP->X_op == O_constant)
+      else if (op_left == O_add && resultP->X_op == O_constant
+	       && (md_register_arithmetic || right.X_op != O_register))
 	{
 	  /* Constant + X.  */
 	  resultP->X_op = right.X_op;

Re: [PATCH] RE: ill effect of <register>+<constant>

[Nick Clifton]

Hi Jan,

> Sorry, I keep forgetting about doing this. OK this way?

> +@item md_register_arithmetic
> +@cindex md_register_arithmetic
> +If this macro is defined and evaluates to non-zero, GAS will avoid folding
> +expressions like adding a constant to a register into a register with its
> +number being the sum of the original register's and the constant.

I think that you mean that this new behaviour occurs when the macro evaluates 
to zero, rather than non-zero.  Also an example might help.  eg:

   If this macro is defined and evaluates to zero then GAS will not fold
   expressions that add or subtract a constant from a register to give
   another register.  For example GAS's default behaviour is to fold the
   expression "r8 + 1" into "r9", which is probably not the result
   intended by the programmer.  The default is to allow such folding,
   since this maintains backwards compatibility with earlier releases of
   GAS.


Patch approved, please apply.  Rewording the documentation is left to your 
discretion.

Cheers
   Nick

Re: [PATCH] RE: ill effect of <register>+<constant>

[Jan Beulich]

Committed with your suggested doc change. Jan

>>> Nick Clifton <nickc@redhat.com> 26.09.07 10:07 >>>
Hi Jan,

> Sorry, I keep forgetting about doing this. OK this way?

> +@item md_register_arithmetic
> +@cindex md_register_arithmetic
> +If this macro is defined and evaluates to non-zero, GAS will avoid folding
> +expressions like adding a constant to a register into a register with its
> +number being the sum of the original register's and the constant.

I think that you mean that this new behaviour occurs when the macro evaluates 
to zero, rather than non-zero.  Also an example might help.  eg:

   If this macro is defined and evaluates to zero then GAS will not fold
   expressions that add or subtract a constant from a register to give
   another register.  For example GAS's default behaviour is to fold the
   expression "r8 + 1" into "r9", which is probably not the result
   intended by the programmer.  The default is to allow such folding,
   since this maintains backwards compatibility with earlier releases of
   GAS.


Patch approved, please apply.  Rewording the documentation is left to your 
discretion.

Cheers
   Nick