This is the mail archive of the gcc@gcc.gnu.org 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: IF conversion bug with CC0


Jeff,

Thank you for your quick response!

Yes, I have a custom ISA.  I am building a custom back end.  The
project, in its current state, can be found at:

http://opencores.com/project,zipcpu

Can you tell me whether the difference between CC0 processing and
non-CC0 processing is a GCC difference or a target ISA difference?

Thanks,

Dan



On Mon, 2016-04-04 at 14:42 -0600, Jeff Law wrote:
> On 04/04/2016 02:19 PM, Dan wrote:
> > Greetings!
> >
> > GCC is usually so perfect, that I hate to write, but ... I think I'm
> > chasing down quite the bug in it and would appreciate some thought to
> > the following.
> >
> > The code that causes the bug looks like:
> >
> > if (ptr) {
> >    *ptr = 1;
> > }
> >
> > This code evaluates, in the instruction set I am working with, into the
> > following RTL:
> >
> > (set (cc0) (compare (reg 3) (reg 1)))
> > (set (pc) (if-then-else (eq (cc0) (const_int 0)) (label_ref 258) (pc)))
> > (set (mem (reg 3)) (reg 1))
> >
> > (all modes are SI)
> >
> > This would be all fine and dandy, up until the if_convert modifications.
> > if_convert() rightly decides that the store instruction is prime for a
> > conditional execution conversion.  Therefore, if_convert() transforms
> > this code into:
> >
> > (cond_exec (ne (cc0) (const_int 0)) (set (mem (reg 3)) (reg 1)))
> >
> > This, by itself, is a valid conversion.
> >
> > The problem is that when cond_exec_process_if_block calls
> > merge_if_block(ce_info) to package up the changes and make them
> > permanent, merge_if_block then calls merge_block which deletes not only
> > the conditional jump statement (set (pc) ... etc.), but also the compare
> > that set the conditions prior to the jump statement (see
> > rtl_merge_blocks within cfgrtl.c).  Hence instead of the working RTL,
> >
> > (set (cc0) (compare (reg 3) (reg 1)))
> > (cond_exec (ne (cc0) (const_int 0)) (set (mem (reg 3)) (reg 1)))
> >
> > I'm left with the broken RTL:
> >
> > (cond_exec (ne (cc0) (const_int 0)) (set (mem (reg 3)) (reg 1)))
> >
> >
> > Can someone tell me if I am missing something, or whether this really is
> > a bug in GCC?
> It's a bug in GCC.  I don't think we currently have any targets that use 
> cc0 and conditional execution, thus other targets aren't stumbling over 
> this problem.
> 
> It sounds like you've got a custom ISA and thus a custom GCC backend.  I 
> would strongly recommend against using cc0 in your backend.  cc0 is an 
> old deprecated way to express condition code handling.
> 
> 
> Jeff


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