Uh oh!
There was an error while loading. Please reload this page.
Never inline intrinsic functions - #1709
Conversation
gptsarthak
commented
Apr 13, 2023
There is no harm in doing this since all functions whose name starts with |
certik
commented
Apr 14, 2023
Thanks for the workaround! I would rather fix this properly. The runtime library has a few hacks in the code base and this PR feels to me like it is adding another hack. I would rather remove some hacks, or add them into one place and wrap them in some functions. If the problem is that we can't reliably identify intrinsic functions, then let's fix that. |
gptsarthak
commented
Apr 14, 2023
I guess we just have have to find a way so that functions that are coming from imported modules do not get inlined. @czgdp1807 do you know anything about that? |
czgdp1807
commented
Apr 14, 2023
Why so? If we are able to access the body of the function in ASR then I think inlining should be possible and we should do it. Probably that would be the proper fix instead of avoiding inlining them. Let's do it here and see what blocks us from properly inlining them. The only case which needs avoiding inlining is those functions which contain fallback implementations of optimisations such as flip_sign, etc, specifically, https://github.com/lfortran/lfortran/blob/main/src/runtime/builtin/lfortran_intrinsic_optimization.f90. |
gptsarthak
commented
Apr 14, 2023
But we cannot inline functions which are implemented in C using |
certik
commented
Apr 14, 2023
For |
gptsarthak
commented
Apr 16, 2023
Is this alright? We stop inlining BindC function after we have inlined its fuction call. |
Fixes#1698
Main:
On branch: