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. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>
