Re: scheduling cc0

[Miles Bader <miles at lsi dot nec dot co dot jp>]

Steven Bosscher <stevenb@suse.de> writes:
>> This approach seems to work well in practice, but can anyone see any
>> potential problems with it?
>
> Well, isn't it a potential problem that lots of places in the compiler
> expect that the cc0 setter is right before the cc0-using insn?

Sure, I suppose, but my experience so far is that there don't really
seem to be that many that don't use `prev_cc0_setter' (which I've
changed to do the right thing).

> And if you do this kind of scheduling before reload, what happens if
> reload has to insert insns that set cc0?

Hmmm, not sure.  I suppose it could be enabled only after reload.

>> Is this a reasonable way to do things? 
>
> The "recommended practice" of today is to use a fake hard register for
> the CC reg, always, instead of cc0.  
> See e.g. "http://gcc.gnu.org/wiki/general backend cleanup", under
> "Convert md files that use CC0 so they don't anymore."

Hmmm, so that's basically the same method, but defined by the backend.
Does this mean that any instruction that affects the cpu-flags (e.g., addition)
on such a processor has a (clobber (reg:SI CPU_FLAGS)) added to it?

Doesn't this present the same problem with reload?

> Unfortunately the v850 targets is one of the few GCC targets that still
> use cc0 for the condition code, see http://gcc.gnu.org/backends.html. 

[I'd love to work on that sort of thing, but so far NEC has not been
very cooperative about signing copyright disclaimers (though I think
doing so would be very much to their benefit), so actually getting code
into the FSF tree is ... problematic; I continue to try...]

Thanks,

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'