--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-18 09:49 ---
The only reason why cexp is slow on PPC darwin is because the ABI is stupid.
Complex float arguments are passed via the GPR and returned also the same way
instead of via the FPRs. So you will get a transfer of regi
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-18 10:20 ---
Andrew,
Thanks for the answer. Additional timings for AMD Opteron(tm) Processor 250,
2.4Ghz:
Target: x86_64-unknown-linux-gnu
...
gcc version 4.3.0 20061231 (experimental)
[tocata] test/fortran> gfc -O3 sincos.f90
--- Comment #3 from dominiq at lps dot ens dot fr 2007-03-19 09:28 ---
BTW, did I miss an option to turn this optimization off?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-19 10:43 ---
There is no option to turn it off. But for !TARGET_C99_FUNCTIONS and
!TARGET_HAS_SINCOS targets it's off. Usually (in fact, for every libm I looked
into), cexp is implemented as
complex double cexp (complex double
--- Comment #5 from dominiq at lps dot ens dot fr 2007-03-19 12:43 ---
> There is no option to turn it off. But for !TARGET_C99_FUNCTIONS and
> !TARGET_HAS_SINCOS targets it's off.
>From my understanding of the thread
http://gcc.gnu.org/ml/gcc/2007-03/msg00639.html
if !TARGET_64BIT
--- Comment #6 from pinskia at gmail dot com 2007-03-19 17:52 ---
Subject: Re: pseudo-optimzation with sincos/cexpi
On 19 Mar 2007 12:43:49 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
>
> Since sin() and cos() are non trivial functions, I am very surprised
> that a
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-20 11:04 ---
I agree it's surprising to get user-visible effects with the
TARGET_C99_FUNCTIONS
difference between the frontends, but they are (supposed to) providing C99
runtime completion by their runtime libraries. And they re
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-20 13:57 ---
> The only reason why cexp is slow on PPC darwin is because the ABI is stupid.
> Complex float arguments are passed via the GPR and returned also the same way
> instead of via the FPRs. So you will get a transfer of
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-20 14:03 ---
> I agree it's surprising to get user-visible effects with the
> TARGET_C99_FUNCTIONS difference between the frontends,
> but they are (supposed to) providing C99 runtime completion
> by their runtime libraries. An
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-20 14:26
---
That sin+cos is practically sincos (so you get one for free). Just not every
library exports that sincos.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
--- Comment #11 from dominiq at lps dot ens dot fr 2007-03-20 14:57 ---
Subject: Re: pseudo-optimzation with sincos/cexpi
> That sin+cos is practically sincos (so you get one for free). Just not every
> library exports that sincos.
Does not this assume that it exists a real sincos(x)
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-20 15:06
---
Depends on how you name it ;) You can propose that we only enable sincos
transformation if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to
that.
(The targets I care for have a sincos)
--
http://gcc
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-20 16:08 ---
> You can propose that we only enable sincos transformation
> if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to
> that. (The targets I care for have a sincos)
Sound reasonable: replacing:
return (TAR
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-20 16:12
---
The recommended way is to post a message to gcc@gcc.gnu.org or
[EMAIL PROTECTED]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-03-20 16:14
---
> Is this also true for complex double on 32 bit architectures (i.e., 4 GPRs)
> or do you mean the GPR is used to pass a pointer?
4 GPRS
Yes this was a stupid decission on Apple's part for not looking at fixing G
--- Comment #16 from dominiq at lps dot ens dot fr 2007-03-21 15:36 ---
> The recommended way is to post a message to gcc@gcc.gnu.org or
> [EMAIL PROTECTED]
I'll follow your advice, but before I'ld like some feedback about what follows.
I have applied the following patch
--- gcc-4.3-2
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-03-21 15:57
---
It would be nice to know whether darwin does not implement cexp in an optimal
way (special casing zero real part and dispatching to a sincos equivalent for
the imaginary part) or if the issue is only a bad ABI for
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-21 16:09 ---
> It would be nice to know whether darwin does not implement cexp in an optimal
> way ...
I have forgotten to mention that I did some (quick) profiling: cexp seens
trivially implemented.
It calls sin, cos and exp +
On 19 Mar 2007 12:43:49 -, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
Since sin() and cos() are non trivial functions, I am very surprised
that a wrong API makes a 50% difference.
Well Here is how it can make a 50% difference (at least on the Cell,
the 970 has less of a restr
19 matches
Mail list logo
