This is the mail archive of the
mailing list for the GCC project.
Re: [RFC, 4.8] Magic matching for flags clobbering and setting
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 14 Feb 2012 00:52:49 +0100
- Subject: Re: [RFC, 4.8] Magic matching for flags clobbering and setting
- References: <4F35B27A.email@example.com>
On Sat, Feb 11, 2012 at 1:12 AM, Richard Henderson <firstname.lastname@example.org> wrote:
> Seeing as how Uros is starting to go down the path of cleaning up the
> flags handling for x86, I thought I'd go ahead and knock up the idea
> that I've been tossing around to help automate the process of building
> patterns that match both clobbering the flags and setting the flags to
> a comparison.
> This is far from complete, but it at least shows the direction.
> What I know is missing off the top of my head are:
> ?(0) Documentation in some .texi file; atm there's only what's in rtl.def.
> ?(1) Generate (clobber (reg flags)) from genemit, should this construct
> ? ? be used in a named insn pattern.
> ?(2) Can't be usefully used with define_insn_and_split, and no way to tell.
> ? ? This problem should simply be documented in the .texi file as user error.
> ?(3) Can't be used for x86 add patterns, as the "clobber" version wants the
> ? ? freedom to use "lea" and the "set flags" version cannot. ?And there are
> ? ? different sets of constraints if lea may be used or not.
> ? ? What would be nice, however, is exposing the targetm.cc_modes_compatible
> ? ? thing in such a way that the x86 add patterns could use that, for the
> ? ? separate insn that does do the set flags.
> ? ? Exposing the targetm.cc_modes_compatible thing separately might also
> ? ? clean up some of the evil magic in genrecog.c too.
To see if I understand what a cc0 port conversion would look like with
"match_flags", I tried to apply this magic to convert one of the pet
ports, the mighty pdp11.
The pdp11 port doesn't have any define_insn_and_splits, so I didn't
run into the problem you mentioned in (2). What is the problem here? I
suppose it has to do with finding out what the flags setter is after
the split? If so, then couldn't that be resolved with some rules about
how the post-split patterns should be constructed?
Other than that: To convert a port, there is still a lot of work to be
done to define and handle the various CC modes properly (well, not for
the pdp11, because it writes out >1 insn for most define_insns), but
it is great not having to define all the pairs of clobber-flags and
set-flags insns. At least, I didn't end up rewriting the complete .md
file. It was relatively easy. Less book-keeping involved, etc.
Hope this goes in for GCC 4.8.