On Wed, Dec 4, 2024 at 11:55 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > On Tue, Dec 3, 2024 at 4:09 PM Richard Biener > <richard.guent...@gmail.com> wrote: > > > > On Mon, Dec 2, 2024 at 7:55 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > > > > > > > > > On 12/2/24 1:55 AM, Richard Biener wrote: > > > > On Sun, Dec 1, 2024 at 11:15 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > >> > > > >> > > > >> > > > >> On 11/27/24 3:34 PM, H.J. Lu wrote: > > > >>> On Thu, Nov 21, 2024, 2:02 PM H.J. Lu <hjl.to...@gmail.com > > > >>> <mailto:hjl.to...@gmail.com>> wrote: > > > >>> > > > >>> Promote integer arguments smaller than int if > > > >>> TARGET_PROMOTE_PROTOTYPES > > > >>> returns true. > > > >>> > > > >>> PR middle-end/14907 > > > >>> * calls.c (initialize_argument_information): Promote > > > >>> small > > > >>> integer > > > >>> arguments if TARGET_PROMOTE_PROTOTYPES returns true. > > > >> This doesn't look right. Promotions are primarily driven by the target > > > >> files, in particular TARGET_PROMOTE_FUNCTION_MODE. > > > >> > > > >> PROMOTE_PROTOTYPES is more of a language front-end hook and it doesn't > > > >> seem appropriate to be testing it in calls.cc. > > > > > > > > It's a misguided hook that when applied in a subset of frontends ends > > > > up generating > > > > wrong code when doing multi-language LTO. I requested moving it's > > > > handling to > > > > RTL expansion where we can apply it consistently. > > > It's probably a fair assessment that if a language FE is doing something > > > like that, then it's going to be problematic for LTO. > > > > > > So maybe the question morphs into whether or not HJ's patch takes us > > > down that path and if so, then shouldn't we be looking to remove the FE > > > uses? And if we do that, how do we get a degree of confidence that we > > > haven't accidentally twiddled the ABI in a meaningful way. > > > > Note it's a target hook, not a language hook - so checking it in frontends > > is > > odd in the first place. Note the outcome is currently relied on by > > combine.cc > > (and other code looking at DECL_ARG_TYPE) - while combine.cc checks > > the function itself is strictly local and thus if the frontend applies the > > optimization consistently it can do so - using LTO will skew "strictly > > local" > > to include cross-language calls. Since for example Fortran doesn't look > > at PROMOTE_PROTOTYPES we get wrong-code. > > > > > > > > > > > > > This particular patch looks OK to me (but as said elsewhere I'm not > > > > very familiar with calls.cc and it's peculiarities). > > > I didn't see anything particularly concerning other than the overarching > > > question of using what had been a language FE hook in calls.cc. I'm > > > obviously leery of changing ABI stuff this late in the game and would > > > generally prefer to defer something like that until the next stage1. > > > > PROMOTE_PROTOTYPES is not about the platform ABI, instead it's > > an optimization, possibly to eliminate partial reg dependencies and it's > > "abused" by combine.cc and the likes as "local" ABI (but as said, we > > can't rely on that with LTO). HJ intends to expand that "local" ABI > > assumption and so I asked for the latent wrong-code issue to be > > fixed first. > > > > I opened: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117907 > > The related existing bugs are: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112877 > > My patch should fix these. >
I sent the v7 patch with the updated commit message for the above PRs. -- H.J.
