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?
Thanks!
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
