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]

CC_REG: "Ian's cc0 replacement machinery", request for stage 2 conceptual approval


After synchronizing with Ian Lance Taylor on IRC, I'm in the
process of implementing the cc0 replacement machinery he
described here and found at
<URL:http://gcc.gnu.org/wiki/general%20backend%20cleanup> after
"Here is a possible approach in which macros are used in the MD
file readers to avoid the pattern explosion".  I understood
noone else is working on this.

The approach is named CC_REG for brief (it's gated on a
define_constant by that name).  I haven't yet bumped into
anything that need fundamental changes to the presented
approach.

The most important reason why I do this, is that I need the CRIS
port to move away from the classic cc0-representation in order
to include a subport (CRIS v32) which for performance needs
scheduling for a modest single five-stage pipeline.  IIUC
patches have been presented for the DFA scheduler to support the
cc0 machinery, but the patches were rejected as support being
unwanted for cc0 machinery.  The cc0 machinery has always been
intrusive in the middle-end which is the main reason why it's no
longer the preferred method for describing condition codes.  The
CC_REG approach seemed like a better approach than the
brute-force approach used with the i386 port, mostly regarding
port maintenance and pattern explosion in the .md file.

What worries me most is that I'll not meet the Stage 1 end of
the 25:th.  This CC_REG machinery patches would arguably be
affecting many files and as such be stage 1 material, but
doesn't at all functionally affect any primary platform (all
being non-cc0) or ports that still use the cc0 approach.

The presented approach is recent and wasn't known until well
into stage 1, so it couldn't be one of the "official" stage 1
projects.  Still, I hope for an exception, assuming a patch is
ready for review in about two weeks for inclusion in HEAD, to-be
4.1.

brgds, H-P


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