This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] support to flip modes in sh mode-switching
- From: Christian BRUEL <christian dot bruel at st dot com>
- To: "'Uros Bizjak'" <ubizjak at gmail dot com>, "'GCC Patches'" <gcc-patches at gcc dot gnu dot org>
- Cc: <amylaar at gcc dot gnu dot org>
- Date: Fri, 22 Dec 2006 21:44:14 +0100
- Subject: RE: [PATCH] support to flip modes in sh mode-switching
Hi Uros,
Thanks for the pointers. From what I see from #19161, the mode-switching
pass would need to be connected to the register class selection ? That's
more that what it does but that would be interesting to see how it fits. For
the case your are mentionning (entering a BB with both modes actives) the
actual implementation would not flip the modes unless there are really
different entities.
But I'm ready for the experiment. The only problem is that I don't know the
x87 :-(
I'm leaving for vacation now. Will get back on this next year. Merry
Chrismass to all of you
Best Regards
Christian
-----Original Message-----
From: Uros Bizjak [mailto:ubizjak@gmail.com]
Sent: Friday, December 22, 2006 7:15 PM
To: GCC Patches
Cc: Christian BRUEL; amylaar@gcc.gnu.org
Subject: Re: [PATCH] support to flip modes in sh mode-switching
Hello Christian!
> This optimization is useful for the sh4-300. I don't know any other
> architecture supported by gcc to test it. It also shares the same
> module than the i386 targets to support mode switching.
I know one ;)
Looking briefly at your patch, it seems to me that it also implements the
infrastructure needed for reliable x87<->MMX mode switching. As described in
PR target/19161 (comment #16 and #17), the patch that used mode switching,
failed for certain CFGs. For certain CFG layouts, it was possible to enter a
BB with both (MMX and X87) modes active. The patch was designed to ICE for
this situation, as both register sets were disabled in this case. However,
having mode _flipping_ patch, this situation can be resolved.
> Bootstrapped the compiler and tested for no regression on
> i686-pc-linux-gnu check-gcc. If there are specific flags to stress 387
> modes I would be happy to run more tests.
You could create some loops and branches, where floor(), ceil() and perhaps
trunc() functions are used. Try to compile it with -O2 -ffast-math and this
should exercise x87 mode switching stuff.
And BTW (looking at PR 28764, comment #12 by Jorn): x87 does not insert mode
_switching_ code, but inserts code where mode control words are calculated.
The reason that separate entities are used is due to "combining" of code
that sets control bits. We can calculate a couple of control words at _one_
insertion point and use these words in actual mode switch:
--cut here--
double test(double *a, int x)
{
int i;
double z = 0.0;
for (i = 0; i < x; i++)
z += floor(a[i]) + ceil(a[i]);
return z;
}
--cut here--
Compile this with -O2 -ffast-math to see that only ONE fstcw is used.
Don't bother with fldcw insns...
> * basic-block.h (pre_edge_lcm_avs): Declare
> * config/i386/i386.h (EMIT_MODE_SET): Add ACTUALMODE parameter.
> * doc/tm.texi (EMIT_MODE_SET): Idem.
> * config/i386/sh.h (EMIT_MODE_SET): Idem. Call emit_fpu_flip.
>
IMO "* config/sh/sh.h" in the last line.
Uros.