[Bug middle-end/32503] __builtin_powi - optimize for other exponents besides 2 and 0.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32503 --- Comment #4 from Eric Gallager --- (In reply to Richard Biener from comment #2) > Confirmed. I had done tree-level expansion of powi into add/mul sequences at > one time. But this had been rejected for some reason I cannot remember > right now. Do you at least remember when that time was, so we can know where to go looking in the archives?
[Bug middle-end/32503] __builtin_powi - optimize for other exponents besides 2 and 0.5
--- Comment #3 from jb at gcc dot gnu dot org 2007-06-26 19:00 --- (In reply to comment #2) > Confirmed. I had done tree-level expansion of powi into add/mul sequences at > one time. But this had been rejected for some reason I cannot remember right > now. The middle-end is able to expand builtin_powi for constant integers. The problem with vectorization is that the vectorizer runs before the pow(i) expansion, and the vectorizer is only aware of exponenets 2 and 0.5. Expanding in the FE works around that problem. In fact, it seems the FE expander is lifted from the ME. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32503
[Bug middle-end/32503] __builtin_powi - optimize for other exponents besides 2 and 0.5
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-26 10:47 --- Confirmed. I had done tree-level expansion of powi into add/mul sequences at one time. But this had been rejected for some reason I cannot remember right now. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-26 10:47:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32503
[Bug middle-end/32503] __builtin_powi - optimize for other exponents besides 2 and 0.5
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-25 19:56 --- > Additionally: It would be great if there would be a variant for long integers > (8 byte integers) and long long (16 byte integers) as PR32239 could only use > __builtin_powi for int4 and not for int8 or int16. Actually, gfortran uses also: pow(integer,integer) and pow(complex,integer), which could also profit from a middle/back-end support. (integer: 4, 8, 16 bytes; complex: single, double, long double precision). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32503