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. Richard. > jeff >
