> From: Björn Haase <[EMAIL PROTECTED]> > 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?)
