Hi, On Mon, Jun 29 2020, Erick Ochoa wrote: > On 29.06.20 06:05, Martin Jambor wrote: >> Hi, >> >> On Mon, Jun 29 2020, Erick Ochoa wrote: >>> == How do we get what we want? == >>> >>> Ideally what we want is to: >>> >> >> [...] >> >>> * Disable constant propagation and other optimizations: >>> * possibly __attribute__((noipa)) >> >> [...] >> >>> == What's the WORST CASE performance of having an unknown sizeof? == >>> >>> I was concerned that the values generated by sizeof might be used by >>> constant propagation and other optimizations might depend on this value. >>> So, in order to have an idea of the impact of this transformation might >>> have on code, I manually changed all sizeof statements on MCF for an >>> equivalent function __lto_sizeof_T() where T identifies the type. I made >>> all these functions static and used the attribute noipa. There was no >>> measurable performance degradation when compared with an untransformed >>> run of MCF. Of course, this is only a data point and the performance >>> might depend on the application/workload/architecture... but it is good >>> to have a data point! >> >> Note that attribute noipa also disables inlining. > > This is good! We want to basically make the values returned by these > functions as opaque as possible. At least as a worst case analysis for > how bad removing the sizeof parse time substitution all the way until > runtime would be. > >> >>> >>> == What are some known unknowns? == >>> >>> >>> * Does noipa work for variables? >>> * I think attribute noipa works for functions but I am not sure if it >>> works for variables. >> >> No, but there are not too many IPA analyses/optimizations working on >> global variables. And making the attributes work for them should not be >> hard. >> >>> * After changing the definition of struct can we re-run all link time >>> optimizations? >>> * I would not like to sacrifice performance. Because I might have >>> hindered constant propagation all optimizations which depend on it might >>> suffer. Therefore, I was wondering if after changing the fields I can >>> delete the noipa attribtue and re-run all link time optimizations >>> somehow? (However, the experiment tells us that this might not be a >>> worry. Perhaps there might be other benchmarks which are more affected >>> by this transformation.) >> >> That would need quite a surgery in the pass manager, and it would >> require re-running all body analyses at the link phase, something we're >> trying to avoid. > > I understand. We might skip this since the experiment showed that there > was no performance degradation. But again... only one data point != > generalization. > >> >> If you need to disable IPA-CP (and IPA-SRA) changing a particular >> parameter (e.g. because an earlier IPA pass has changed it beyond >> recognition), ipa_param_adjustments::get_surviving_params should place >> false in the corresponding vector element. > > Awesome! Thanks! I have been looking for something like this for a > little while. > >> >> If you need to disable propagation of a specific value in a specific >> call, you need to prevent creation of the associated jump function. >> >> But of course, if the call gets inlined the propagation will happen >> anyway, so if you are afraid that propagation of any value anywhere can >> possibly be based on an offsetof or sizeof which you are changing, then >> I don't think your problems are limited just to IPA (link time >> optimization) propagation. > > Sorry, I have some problem understanding this. You mentioned that noipa > disables inlining (which is good). Here you state that "if the call gets > inlined" then the value will be propagated. > > Are you saying that this mini benchmark experiment was flawed and that > we should also look at how to disable non-ipa passes?
My point was simply that if you just do not want inter-procedural propagations to happen, than you cannot just somehow disable/limit IPA-CP but also inlining, because that can convert them to plain old intra-procedural propagation. And disabling inlining is going to have huge performance implications. So I'd try to avoid such need as much as possible. Martin
