RE: [H8300] : BCLR Instruction is not being generated for H8 target

["Arati Dikey" <AratiD at kpit dot com>]

Hi Kazu,

The data to be anded (0xFB) has a single 0.
Hence I expect the BCLR instruction to be generated.

_foo:
	mov.l	er6,@-er7
	mov.l	er7,er6
	bset	#6,@-96:8
	bclr	#2,@-96:8
	mov.l	@er7+,er6
	rts

I debugged the compiler and found that this is not happening because 0xFB is generating a OVERFLOW and compiler decides to put it in a register.

In expr.c, following case statement is present. If the IF loop is entered, 'and' insn is generated. For gcc.3.2.1, the IF statement is not entered and the 'bclr' insn is generated.

case INTEGER_CST:
      temp = immed_double_const (TREE_INT_CST_LOW (exp),
				 TREE_INT_CST_HIGH (exp), mode);

      /* ??? If overflow is set, fold will have done an incomplete job,
	 which can result in (plus xx (const_int 0)), which can get
	 simplified by validate_replace_rtx during virtual register
	 instantiation, which can result in unrecognizable insns.
	 Avoid this by forcing all overflows into registers.  */
	 
      if (TREE_CONSTANT_OVERFLOW (exp)
	  && modifier != EXPAND_INITIALIZER)
	temp = force_reg (mode, temp);
  
      return temp;



TREE_CONSTANT_OVERFLOW (exp) expands to exp->common.static_flag 
 
For gcc-3.3 onwards exp->common.static_flag = 1 , along with common.public_flag and const_flag.

I commented the IF statement, built the compiler and verified that 'bclr' is generated.

Please help.

Regards,
Arati Dikey.



-----Original Message-----
From: Kazu Hirata [mailto:kazu@cs.umass.edu]
Sent: Tuesday, January 21, 2003 8:27 PM
To: Arati Dikey
Cc: gcc@gcc.gnu.org; gcc-bugs@gcc.gnu.org
Subject: Re: [H8300] : BCLR Instruction is not being generated for H8
target


Hi Arati,

> The BCLR instruction does not get generated for current CVS head. Following is my test program.
> 
> #if __H8300S__
> #define PBIT   (*(char *)0xFFFFFFA0) /* FLASH Address*/
> #define PINT   (*(int *)0xFFFF80A0) /* FLASH Address*/
> #define PLONG   (*(long int *)0xFFFF80A0) /* FLASH Address*/
> #elif __H8300H__
> #define PBIT   (*(char *)0xFFFFA0) /* FLASH Address*/
> #define PINT   (*(int *)0xFF80A0) /* FLASH Address*/
> #define PLONG   (*(long int *)0xFF80A0) /* FLASH Address*/
> #else
> #define PBIT   (*(char *)0xFFA0) /* FLASH Address*/
> #define PINT   (*(int *)0xFF80) /* FLASH Address*/
> #define PLONG   (*(long int *)0xFF80) /* FLASH Address*/
> #endif
> 
> void foo()
> {
> 	PBIT |= 0x40 ;
> 	PBIT &= 0xFB ;
> }
> 
> h8300-coff-gcc -S -ms h8test.c
> 
> results in following h8test.s
> 
> ;	GCC For the Hitachi H8/300
> ;	By Hitachi America Ltd and Cygnus Support
> 
> 	.h8300s
> 	.file	"h8test.c"
> 	.section .text
> 	.align 1
> 	.global _foo
> _foo:
> 	mov.l	er6,@-er7
> 	mov.l	er7,er6
> 	bset	#6,@-96:8
> 	mov.b	#-5,r2l
> 	mov.b	@-96:8,r3l
> 	and	r3l,r2l
> 	mov.b	r2l,@-96:8
> 	mov.l	@er7+,er6
> 	rts
> 	.end
> 	.ident	"GCC: (GNU) 3.3 20030113 (prerelease)"

If I specify -O2 -fomit-frame-pointer, I get

_foo:
	mov.b	@-96:8,r2l
	or	#64,r2l
	and	#-5,r2l
	mov.b	r2l,@-96:8
	rts

Do you mean that you want to get a little more optimized code under
-O0?

Kazu Hirata