Bug 32503

Summary: __builtin_pow[i] - vectorize for other exponents besides 2 and 0.5
Product: gcc Reporter: Tobias Burnus <burnus>
Component: tree-optimizationAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: egallager, gcc-bugs, jb, rguenth
Priority: P3 Keywords: missed-optimization
Version: 4.3.0   
Target Milestone: ---   
See Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32239
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2019-06-03 00:00:00
Bug Depends on:    
Bug Blocks: 53947    

Description Tobias Burnus 2007-06-25 19:51:00 UTC 
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01172.html (PR 32239):

"At the moment the vectorizer only vectorizes builtin_pow if the exponent is either 2 or 0.5. whereas if we expand constant exponents in the gfortran frontend (gfc_conv_cst_int_power) it vectorizes for other constant integer powers as well (the expansion by the frontend generates a number of calls to builtin_pow with exponent 2.0)."

Expected: The same optimization is done for multiple of 2 (and -2) - as it is currently in the Fortran FE. (If this has been implemented in the ME, please inform the Fortraners to remove the expansion there.)

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.
Comment 1 Tobias Burnus 2007-06-25 19:56:57 UTC 
> 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).
Comment 2 Richard Biener 2007-06-26 10:47:05 UTC 
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.
Comment 3 Janne Blomqvist 2007-06-26 19:00:20 UTC 
(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.
Comment 4 Eric Gallager 2019-06-03 04:32:24 UTC 
(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?
Comment 5 Richard Biener 2019-06-03 08:48:41 UTC 
(In reply to Eric Gallager from comment #4)
> (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?

See the followup comment.  We now do this expansion but it is too late
for vectorization.  The vectorizer knows how to handle pow of a
constant via exp[2] which have vectorized variants.  It also knows
square-root and square but doesn't try anything more fancy.  See
vect_recog_pow_pattern.