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: Overwhelmed by GCC frustration


On 08/16/2017 08:14 AM, Eric Botcazou wrote:
>> Just the fact that the backends that get most attention and attract
>> most developers don't use cc0 doesn't mean cc0 is a useless device.
> 
> Everything that can be done with cc0 can be done with the new representation, 
> at least theoritically, although this can require more work.
Yup.

> 
>> As far as cc0 is concerned, transforming avr BE is not trivial.
>> It would need rewriting almost all of its md files entirely.
>> It would need rewriting great deal of avr.c that handle
>> insn output and provide input to NOTICE_UPDATE_CC.
> 
> I recently converted the Visium port, which is an architecture where every 
> integer instruction, including a simple move, clobber the flags, so it's 
> doable even for such an annoying target (but Visium is otherwise regular).
> See for example https://gcc.gnu.org/wiki/CC0Transition for some guidelines.
Yup.  I'd strongly recommend anyone contemplating a conversion to read
your guidelines.


> 
>> But my feeling is that opposing deprecation of cc0 is futile,
>> the voices that support cc0 deprecation are more and usefulness
>> of cc0 is not recognized.
> 
> cc0 is just obsolete and inferior compared to the new representation.
And cc0 is inherently buggy if you know how to poke at it.  There are
places where we can't enforce the cc0 user must immediately follow the
cc0 setter.

We've been faulting in work-arounds when ports trip over those problems,
but I'm certain more problems in this space remain.

jeff


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