public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Typo or intended?
@ 2009-03-16 16:12 Bingfeng Mei
  2009-03-16 17:02 ` Andrew Haley
  2009-03-23 20:12 ` Vladimir Makarov
  0 siblings, 2 replies; 4+ messages in thread
From: Bingfeng Mei @ 2009-03-16 16:12 UTC (permalink / raw)
  To: gcc, vmakarov

Hello,
I just updated our porting to include last 2-3 weeks of GCC developments. I noticed a large number of test failures at -O1 that use a user-defined data type (based on a special register file of our processor). All variables of such type are now spilled to memory which we don't allow at -O1 because it is too expensive. After investigation, I found that it is the following new code causes the trouble. I don't quite understand the function of the new code, but I don't see what's special for -O1 in terms of register allocation in comparison with higher optimizing levels. If I change it to (optimize < 1), everthing is fine as before. I start to wonder whether (optimize <= 1) is a typo or intended. Thanks in advance.

Cheers,
Bingfeng Mei
Broadcom UK

      if ((! flag_caller_saves && ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
	  /* For debugging purposes don't put user defined variables in
	     callee-clobbered registers.  */
	  || (optimize <= 1                               <---------  why include -O1? 
	      && (attrs = REG_ATTRS (regno_reg_rtx [ALLOCNO_REGNO (a)])) != NULL
	      && (decl = attrs->decl) != NULL
	      && VAR_OR_FUNCTION_DECL_P (decl)
	      && ! DECL_ARTIFICIAL (decl)))
	{
	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
			    call_used_reg_set);
	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
			    call_used_reg_set);
	}
      else if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
	{
	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
			    no_caller_save_reg_set);
	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
			    temp_hard_reg_set);
	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
			    no_caller_save_reg_set);
	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
			    temp_hard_reg_set);
	}

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Typo or intended?
  2009-03-16 16:12 Typo or intended? Bingfeng Mei
@ 2009-03-16 17:02 ` Andrew Haley
  2009-03-23 20:12 ` Vladimir Makarov
  1 sibling, 0 replies; 4+ messages in thread
From: Andrew Haley @ 2009-03-16 17:02 UTC (permalink / raw)
  To: Bingfeng Mei; +Cc: gcc, vmakarov

Bingfeng Mei wrote:

> I just updated our porting to include last 2-3 weeks of GCC
> developments. I noticed a large number of test failures at -O1 that
> use a user-defined data type (based on a special register file of
> our processor). All variables of such type are now spilled to memory
> which we don't allow at -O1 because it is too expensive. After
> investigation, I found that it is the following new code causes the
> trouble. I don't quite understand the function of the new code, but
> I don't see what's special for -O1 in terms of register allocation
> in comparison with higher optimizing levels. If I change it to
> (optimize < 1), everthing is fine as before. I start to wonder
> whether (optimize <= 1) is a typo or intended. Thanks in advance.

-O1 is supposed to allow debugging but still optimize, so it's quite
possible that Vlad did intend to do this.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39432

Andrew.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Typo or intended?
  2009-03-16 16:12 Typo or intended? Bingfeng Mei
  2009-03-16 17:02 ` Andrew Haley
@ 2009-03-23 20:12 ` Vladimir Makarov
  2009-03-24 12:30   ` Bingfeng Mei
  1 sibling, 1 reply; 4+ messages in thread
From: Vladimir Makarov @ 2009-03-23 20:12 UTC (permalink / raw)
  To: Bingfeng Mei; +Cc: gcc

Bingfeng Mei wrote:
> Hello,
> I just updated our porting to include last 2-3 weeks of GCC developments. I noticed a large number of test failures at -O1 that use a user-defined data type (based on a special register file of our processor). All variables of such type are now spilled to memory which we don't allow at -O1 because it is too expensive. After investigation, I found that it is the following new code causes the trouble. I don't quite understand the function of the new code, but I don't see what's special for -O1 in terms of register allocation in comparison with higher optimizing levels. If I change it to (optimize < 1), everthing is fine as before. I start to wonder whether (optimize <= 1) is a typo or intended. Thanks in advance.
>
>   
Sorry for the delay with the answer.  I was on vacation last week.

As Andrew Haley guess, it was intended.  I thought that improving 
debugging for -O1 is also important (more important than optimization).  
Although GCC manual says

     With `-O', the compiler tries to reduce code size and execution
     time, without performing any optimizations that take a great deal
     of compilation time.

it also says

`-O' also turns on `-fomit-frame-pointer' on machines where doing
     so does not interfere with debugging.

Therefore I've decided to do analogous thing for the patch.  May be I am 
wrong.  We could do this only for -O0 if people really want this which I 
am not sure about.
> Cheers,
> Bingfeng Mei
> Broadcom UK
>
>       if ((! flag_caller_saves && ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
> 	  /* For debugging purposes don't put user defined variables in
> 	     callee-clobbered registers.  */
> 	  || (optimize <= 1                               <---------  why include -O1? 
> 	      && (attrs = REG_ATTRS (regno_reg_rtx [ALLOCNO_REGNO (a)])) != NULL
> 	      && (decl = attrs->decl) != NULL
> 	      && VAR_OR_FUNCTION_DECL_P (decl)
> 	      && ! DECL_ARTIFICIAL (decl)))
> 	{
> 	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
> 			    call_used_reg_set);
> 	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
> 			    call_used_reg_set);
> 	}
>       else if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
> 	{
> 	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
> 			    no_caller_save_reg_set);
> 	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
> 			    temp_hard_reg_set);
> 	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
> 			    no_caller_save_reg_set);
> 	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
> 			    temp_hard_reg_set);
> 	}
>   

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Typo or intended?
  2009-03-23 20:12 ` Vladimir Makarov
@ 2009-03-24 12:30   ` Bingfeng Mei
  0 siblings, 0 replies; 4+ messages in thread
From: Bingfeng Mei @ 2009-03-24 12:30 UTC (permalink / raw)
  To: Vladimir Makarov; +Cc: gcc

That's fine. It seems that other targets don't have such issue. Our target is too special and it is
still a private port. I can just use optimize < 1 here. Thanks,

Bingfeng 

> -----Original Message-----
> From: Vladimir Makarov [mailto:vmakarov@redhat.com] 
> Sent: 23 March 2009 19:40
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Typo or intended?
> 
> Bingfeng Mei wrote:
> > Hello,
> > I just updated our porting to include last 2-3 weeks of GCC 
> developments. I noticed a large number of test failures at 
> -O1 that use a user-defined data type (based on a special 
> register file of our processor). All variables of such type 
> are now spilled to memory which we don't allow at -O1 because 
> it is too expensive. After investigation, I found that it is 
> the following new code causes the trouble. I don't quite 
> understand the function of the new code, but I don't see 
> what's special for -O1 in terms of register allocation in 
> comparison with higher optimizing levels. If I change it to 
> (optimize < 1), everthing is fine as before. I start to 
> wonder whether (optimize <= 1) is a typo or intended. Thanks 
> in advance.
> >
> >   
> Sorry for the delay with the answer.  I was on vacation last week.
> 
> As Andrew Haley guess, it was intended.  I thought that improving 
> debugging for -O1 is also important (more important than 
> optimization).  
> Although GCC manual says
> 
>      With `-O', the compiler tries to reduce code size and execution
>      time, without performing any optimizations that take a great deal
>      of compilation time.
> 
> it also says
> 
> `-O' also turns on `-fomit-frame-pointer' on machines where doing
>      so does not interfere with debugging.
> 
> Therefore I've decided to do analogous thing for the patch.  
> May be I am 
> wrong.  We could do this only for -O0 if people really want 
> this which I 
> am not sure about.
> > Cheers,
> > Bingfeng Mei
> > Broadcom UK
> >
> >       if ((! flag_caller_saves && ALLOCNO_CALLS_CROSSED_NUM 
> (a) != 0)
> > 	  /* For debugging purposes don't put user defined variables in
> > 	     callee-clobbered registers.  */
> > 	  || (optimize <= 1                               
> <---------  why include -O1? 
> > 	      && (attrs = REG_ATTRS (regno_reg_rtx 
> [ALLOCNO_REGNO (a)])) != NULL
> > 	      && (decl = attrs->decl) != NULL
> > 	      && VAR_OR_FUNCTION_DECL_P (decl)
> > 	      && ! DECL_ARTIFICIAL (decl)))
> > 	{
> > 	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
> > 			    call_used_reg_set);
> > 	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
> > 			    call_used_reg_set);
> > 	}
> >       else if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
> > 	{
> > 	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
> > 			    no_caller_save_reg_set);
> > 	  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
> > 			    temp_hard_reg_set);
> > 	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
> > 			    no_caller_save_reg_set);
> > 	  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
> > 			    temp_hard_reg_set);
> > 	}
> >   
> 
> 
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-03-24  9:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-16 16:12 Typo or intended? Bingfeng Mei
2009-03-16 17:02 ` Andrew Haley
2009-03-23 20:12 ` Vladimir Makarov
2009-03-24 12:30   ` Bingfeng Mei

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).