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. > > == 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. 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. 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. I'd do what Richi has suggested and enter some conservative mode if sizeof and especially offsetof were used on a type (you might still be able to handle memset from offset zero until the end of the structure as a special case?). Martin
