On Tue, Sep 29, 2015 at 11:20 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On September 29, 2015 9:27:13 PM GMT+02:00, fxcoud...@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
