Hi, On Wed, Jul 21 2021, Alexandre Oliva wrote: > On Jul 19, 2021, Martin Jambor <mjam...@suse.cz> wrote: > >> So I would first check how come that you request IPA_PARAM_OP_COPY of >> something that does not seem to have a corresponding type but there is >> a DECL > > The corresponding type is there all right, it was just stored in a > different vector entry, because some IPA optimization, applied after my > copying-and-wrapping pass, dropped several of the parms that came before > a NEW parms added by my pass. > > This caused the types of the retained NEW parms to be pushed into lower > indices in the type array, but then accessed as if all of the dropped > parms were still there. That can't be right. > > I was actually lucky that enough parms were dropped as to make the > vector access out of range, flagged by checking. If that wasn't the > case, we might have silently accessed an unrelated parm type. > > > Does this scenario make sense to you? > > I can try to get you some code for a custom pass to trigger the problem > if you'd like to look more closely. > >> If you believe that what you're doing is correct > > I don't really know that it is. IIRC back when I ran into this problem, > the logic to change some of the parameters in the wrapped function to > reference types was using NEW parameters. Now I'm using COPY, save for > actual NEW parms, and changing the type of the clone after > create_version_clone_with_body. > > Now, what puzzles me is why we even care about that parm mapping > afterwards. The clone is created and materialized very early on, before > any preexisting ipa transformations, and there were not any edges > modified to use this clone. As far as I'm concerned, it should be > entirely independent from the function it was cloned from, and it makes > no sense to me for IPA transformations applied to this clone to even > care what the function it was originally cloned from was: the clone is > already fully materialized, so argument back-mappings might as well stop > at it. > > But I can't say I understand why it does that. I haven't looked very > much into its internals, I'm mostly just trying to use > create_version_clone_with_body to clone a function, make some changes to > it, and turn the original function into a wrapper. > > I'm not actually introducing IPA deferred transformations, and this is > all done before any relevant IPA transformations. I can't even say I'm > using IPA proper, the reason I made it an IPA pass was because that has > enabled multiple passes over functions, which was convenient for some > purposes. Then, I ended up iterating over aliases and undefined > functions, and relying on the call graph instead of iterating over > gimple bodies for some purposes, so now it *has* to be an IPA pass, but > not a typical one in that it doesn't queue up IPA transformations to be > applied at a later materialization.
So if I understand correctly, you clone during early tree optimizations (or early-small-IPA passes) or even earlier, and yet somehow these confuse clone materialization when it applies IPA modifications to parameters. I agree that should not be happening. I cannot see how this can happen. IPA-split and omp-simd also use create_version_clone_with_body with parameter modifications and do not cause this problem (and I have seen many interactions between ipa-split and later IPA passes when debugging various issues). Having said that, these passes either act on fairly simple functions and/or do not do sophisticated parameter modifications, so I would not be bugs when doing them. I am interested in making the infrastructure work for you, but at the moment I unfortunately do not have an idea what the problem you are facing might be. Martin
