This is the mail archive of the
mailing list for the GCC project.
Re: movstrictqi/movstricthi fix for h8300
- To: Bernd Schmidt <bernds at redhat dot co dot uk>
- Subject: Re: movstrictqi/movstricthi fix for h8300
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 12 Sep 2000 08:44:28 -0600
- cc: Matthew Hiller <hiller at cygnus dot com>, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <Pine.LNX.firstname.lastname@example.org>you
> > For extra credit -- submit a testcase for the bug which led you to this
> > patch.
> For yet more extra credit, also fix convex.md, i370.md, i386.md, ns32k.md,
> sh.md and vax.md :-) (See below)
I was going to fix them myself :-) grep is my friend.
> I've been irritated by STRICT_LOW_PART for a while. What do you folks
> think about eliminating it?
> It's yet another one of the irregularities in rtl which I hate so much.
> Every piece of code that analyzes RTL has to special-case it (along
> with a few other rtxs, but one thing at a time). It's not easy to
> optimize, e.g. for a cse-like pass you can't easily record an equivalence.
> And, people forget that they are in-out operands and write "=" in their
> machine descriptions rather than "+".
> I think it would be cleaner to represent a movstrict pattern as something
> (set (reg X) (ior (and X 0xFF....00) (zero_extend Y)))
> This might even help the combiner, who knows.
Seems reasonable. Probably the biggest hurdle will be converting the
m68k port which I believe uses strict_low_part fairly regularly.