Re: [PATCH v2 00/10] Introduce strub: machine-independent stack scrubbing

[Alexandre Oliva <oliva@adacore.com>]

On Oct 13, 2022, Richard Biener <richard.guenther@gmail.com> wrote:

> On Tue, Oct 11, 2022 at 3:33 PM Alexandre Oliva <oliva@adacore.com> wrote:
>> 
>> On Oct 11, 2022, Richard Biener <richard.guenther@gmail.com> wrote:
>> 
>> > On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva <oliva@adacore.com> wrote:
>> >>
>> >> On Oct 10, 2022, Richard Biener <richard.guenther@gmail.com> wrote:
>> >>
>> >> > As noted in the Cauldron Discussion I think you should do all
>> >> > instrumentation post-IPA only to simplify your life not needing to
>> >> > handle inlining of instrumentation
>> >>
>> >> I looked a bit into that after the Cauldron, and recalled why I wanted
>> >> to instrument before inlining: in the case of internal strub, that
>> >> introduces a wrapper, it's desirable to be able to inline the wrapper.
>> 
>> > I think if the wrapper is created at IPA time it is also available for
>> > IPA inlining.
>> 
>> Yeah, but now I'm not sure what you're suggesting.  The wrapper is
>> instrumentation, and requires instrumentation of the wrapped
>> counterpart, so that can't be post-IPA.

> IPA folks can probably explain better but there's IPA (local)
> analysis, IPA (global) propagation
> and IPA (local) code generation.

I think we're miscommunicating.

None of these are post-IPA, they're all part of IPA.

At first, you'd suggested instrumentation to be made post-IPA, to avoid
the trouble of inlining instrumentation.  But we *do* want to inline the
instrumentation.

Now you seem to be suggesting a major revamp of the implementation to
integrate it into IPA, rather than post-IPA, while I keep on trying to
reconcile that with the initial recommendation of moving it post-IPA.

Have you dropped the initial recommendation, and moved on to an
unrelated recommendation?

If so, I can stop trying to reconcile the unrelated recommendations as
if they were related, and focus on the newer one alone.

My reasons to not want to integrate strub tightly into IPA
infrastructure was that there was no perceived benefit from a tighter
integration, and I wasn't sure the feature would be welcome, so I
designed something that could be added in a very standalone way, maybe
even as a plugin.

Maybe there is interest and this decoupling could be reduced, but
there'd have to be very compelling reasons to justify undergoing such
major reengineering.

-- 
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>