This is the mail archive of the gcc@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: missed optimization


On Tue, Sep 29, 2015 at 11:20 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On September 29, 2015 9:27:13 PM GMT+02:00, fxcoudert@gmail.com wrote:
>>It cannot be done in the front-end, but has to happen during value
>>propagation in the middle-end. But the middle-end only handles known
>>*_EXPR and built-ins. So this would require adding either a POWINT_EXPR
>>or a type-generic __builtin_powint. No small task.
>>
>>I think there is already a PR for that (at the very least, I have
>>looked into it and discussed it with some middle-end experts before). I
>>cannot look it up right now, it's the interlude of Don Govanni at Paris
>>Opera :)
>
> The middle-end knows sth remotely related, __builtin_powi, already.  What we'd need though is a way for a frontend to specify which library function to use as fallback.  In principle I would suggest to add a general POW_EXPR tree code.  But the issue as what library call to expand to remains.  Usually such functions reside in libgcc (powi has some there).

Several years ago (PR 32239, geez back in 2007, has it already been
that long...), I already implemented the optimization whereby the
frontend uses __builtin_powi, but that's only for REAL(kind=whatever
corresponds to C float/double/long double) ** INT(kind=C_INT), whereas
the issue here is apparently int**int, for which there is no
equivalent builtin.


-- 
Janne Blomqvist


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