This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH] H8300 Shift Optimization

I will try to implement your suggestion for -Os and post a patch soon.

Also there was a lot of discussion about compiler not generating instructions 
for bit manipulation for volatile memory operands. ( bset, bnot, etc ). 
(search the archives for volatile_ok  problem )
As all IO is memory mapped, pointers are declared as volatile and this affects 
code generation.

For e.g.

void foo()
	*( volatile char *) 0xFFFFA8 |= 0x40 ;

If the above code is compiled with h8300-hms-gcc -fomit-frame-pointer -S -mh,
following code is generated.

	.global _foo
	mov.b	@16777128:8,r2l
	or	#64,r2l
	mov.b	r2l,@16777128:8

Instead it would be preferred to generate 

	.global _foo
	bset	#6,@16777128:8

>From the earlier discussion and patch on this subject I have created patch for current 

2002-08-30	Dhananjayd Deshpande <>
		h8300.c: Accept volatile operands as bit_operand
--- h8300.c.old	Fri Aug 30 10:33:32 2002
+++ h8300.c	Fri Aug 30 10:35:11 2002
@@ -744,11 +744,19 @@
      rtx op;
      enum machine_mode mode;
-  /* We can except any general operand, expept that MEM operands must
-     be limited to those that use addresses valid for the 'U' constraint.  */
-  if (!general_operand (op, mode))
-    return 0;
+   int save_volatile_ok = volatile_ok ;
+   int gen_op ;
+   /* We can accept any general operand, including volatile, expept that MEM 
+      operands must be limited to those that use addresses valid for the 'U' 
+      constraint.  */
+   volatile_ok = 1 ;
+   gen_op = general_operand (op, mode) ;
+   volatile_ok = save_volatile_ok ;
+   if (!gen_op)
+     return 0;
   /* Accept any mem during RTL generation.  Otherwise, the code that does
      insv and extzv will think that we can not handle memory.  However,
      to avoid reload problems, we only accept 'U' MEM operands after RTL
Is there any problem with this implementation? Is there alternative for this?
I think if there is no problem in this, it should go in the FSF sources so that 
users don't have to apply this patch every time.


> -----Original Message-----
> From: Jeff Law []
> Sent: Friday, August 30, 2002 2:54 AM
> To: Dhananjay R. Deshpande
> Cc: Kazu Hirata;
> Subject: Re: [PATCH] H8300 Shift Optimization 
> In message 
> <>, "Dhananjay R
> . Deshpande" writes:
>  >
>  >Hi Kazu,
>  >
>  >Based on the analysis given below, some of the HImode 
> Shifts currently implem
>  >ented as Loop could be optimized for speed.
> [ ... ]
> Thanks.  I've installed your patch.
> If you wanted to take this a step further, you could have the
> shift_alg_XXX tables be initialized at startup time.  Then you could
> change how their initialized based on things like -Os.
> jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]