[Bug target/17345] [3.5 Regression] internal compiler error: in optimize_mode_switching, at lcm.c:1225

["hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From hubicka at ucw dot cz  2004-09-09 15:17 -------
Subject: Re:  [3.5 Regression] internal compiler error: in optimize_mode_switching, at lcm.c:1225

> 
> ------- Additional Comments From uros at kss-loka dot si  2004-09-09 14:16 -------
> Jan,
> 
> thank you very much for looking into this bugreport! I admit, I didn't notice
> this report, and I'm really sorry that even with a lot of testing, my patch

The abnormal edges happen commonly only for C++ so it is rather dificult
to catch.

> broke something. Your patch fixes this breakage, could you please commit it to CVS ?

I guess I need approval for this kind of patch...
> 
> Regarding my proposal, I would suggest to change mode handling from this scheme:
> ...
> fldcw (new_mode)
> fistp [or frndint]
> fldcw (saved_mode)
> ...
> 
> fldcw (other_mode)
> fistp [or frndint]
> fldcw (saved_mode)
> ...
> 
> into something like this:
> 
> ...
> fldcw (new_mode)
> fistp [or frndint]
> ...
> fldcw (other_mode)
> fistp [or frndint]
> ...
> fldcw (saved_mode)
> call [or __asm] 
> ...
> fldcw (other_mode)
> fistp [or frndint[
> ...
> fldcw (saved_mode)
> return

This is dificult to do.  Basically the loads of control word needs to
depend on where reload ends up putting spilling code.  There are two
schemes - we might either teach reload to do spilling always in 80bit
precision.  This will kill performance somewhat but it might be usefull
for people who need independency of results on optimization.

Other scheme is to follow the current mode switching with a pass after
reload that will insert actual loads from previously inserted
computations.
> 
> Basically, fldcw would be emitted only when rounding mode changes. Also, with
> this scheme fistp and frndint patterns could have dependency on FP_mode
> register, which would hopefully address mode changing in for loops. As it is now:
> 
> ...
> loop {
>   fldcw (new_mode)
>   fistp
>   fldcw (saved_mode)

At same time it is important to not recaluclate saved_mode and new_mode
unnecesarily.  i think with your patch we will end up redoing the
computation every time we need different rounding modes (ie try floor
and ceil together in single loop)

> }
> ...
> 
> 
> a better code could be generated:
> ...
> fldcw (new_mode)
> loop {
>   fistp
> }
> ...
> fldcw (saved_mode)
> ret
> 
> I guess mode would need to be changed to saved before call instruction or __asm
> and on return from function.
> 
> Another idea is to convert
> (int) floor(double) into some kind of builtin_lfloor, etc on a tree level. This
> builtin could then be expanded as fix_floor?f?i optab, and this could be
> implemented with sse instructions as it is a case with fix_trunc?f?i optabs.
> However, SSE has its own mode register and if handled the same way as i387 mode
> register, another two stack slots would be needed to save old and new SSE
> rounding mode value.

I already (at least partly) implemented this.
See mathfn_built_in and associated code.
In the case we are missing some cases, just add more of them.

Honza
> 
> It is quite interesting, how many cases would this convertions catch. For
> example, povray-3.50c:
> 
> grep floor *.cpp | grep int - | wc -l
>      39
> grep floor *.cpp | grep long - | wc -l
>       7
> grep ceil *.cpp | grep int - | wc -l
>       8
> 
> Uros.
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17345
> 
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17345