This is the mail archive of the gcc-patches@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]

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.


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