This is the mail archive of the
mailing list for the GCC project.
Re: missed optimization
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: fxcoudert at gmail dot com,Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Cc: fortran at gcc dot gnu dot org,gcc at gcc dot gnu dot org
- Date: Tue, 29 Sep 2015 22:20:02 +0200
- Subject: Re: missed optimization
- Authentication-results: sourceware.org; auth=none
- References: <20150929183645 dot GA86538 at troutmask dot apl dot washington dot edu> <BC69224A-7C81-465F-B3BE-4AFA368EDDFB at gmail dot com>
On September 29, 2015 9:27:13 PM GMT+02:00, email@example.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
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).