This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: AVR: CC0 to CCmode conversion
- From: Paul Schlie <schlie at comcast dot net>
- To: Björn Haase <bjoern dot m dot haase at web dot de>
- Cc: <denisc at overta dot ru>,GCC List <gcc at gcc dot gnu dot org>
- Date: Sat, 19 Mar 2005 18:16:15 -0500
- Subject: Re: AVR: CC0 to CCmode conversion
> From: Björn Haase <bjoern.m.haase@web.de>
> In my opinion segmenting the rework of the back-end would indeed be the best
> approach, also because I expect that the instruction patterns *with*
> splitting will be fairly different. E.g. I do not think that the "addsi3"
> will be present any more. So it would be probably a lot of useless work to
> add all of the clobbers for instruction patterns that are likely to vanish in
> the near future.
Related more specifically to the above comment:
- I understand the desire not to add stuff which is only likely to be
removed/replaced in the near future.
- at that "near future" point in time, do you anticipate all side-effect
STATUS-FLAG dependencies between split byte operations to be fully
exposed such that it will guarantee that potential scheduling
optimizations will never unsafely reorder them?
- in lieu of replacing the exiting target files with a short term
interim solution, might it make sense to check-it-in as a parallel
avr target description, which may be alternatively built with possibly
--target=new-avr; thereby providing a convenient mechanism by which
it could be both updated and experimented with conveniently without
potentially disrupting the base-line existing target files; thereby
when it's stabilized and clearly superior, it could replace the
older ones, and then deleted (or kept as a experimental vehicle,
to test further refinements without disrupting the base-line files?)