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. -- H.J.
