Huh, Gmail failed at threading, causing me to miss this response. Anyway:
> Any comments at all on this? Chandler perhaps?
>
> I've since dug a bit further, and it seems like the template-based
> solution wouldn't work anyway because DLL loading on Windows can't do
> the required commoning. So the general approach taken in
> ⚙ D62802 [RFC][AMDGPU] Uniform values being used outside loop marked non-divergent seems to be the only technically
> viable path forward, though it would still be good to get an outside
> look at the concrete details.
>
> Thanks,
> Nicolai
>
>> Hi all,
>>
>> re-upping and renaming this thread to get some attention, as we'd like
>> some feedback on a change that affects the future design direction.
>>
>> The concrete problem: We would like to mark the LCSSA pass as
>> preserving the StackProtector pass in order to be able to properly
>> express all dependencies we have. Unfortunately, those passes are
>> defined in different modules that do not (and should not) depend on
>> each other, which causes linking to fail.
You say "should not", but I'm not sure that's clear. If LCSSA has
knowledge of the StackProtector, then there is a legitimate dependence.
Either we express that directly, or alternatively, we abstract the
relevant properties to create an abstract dependence. For example, we
have the setPreservesCFG/CFGOnly property pair. In general, I think that
we should have more of these abstract properties. That having been said,
if the orthogonality is very specific, then a specific dependence may be
appropriate.
There is mutual knowledge between the passes, yes. However:
1. Does that really mean that there is a _dependence_? And what kind
of dependence are we talking about anyway?
2. Even if there is a dependence, why should a linker be the correct
way of expressing it?
More to the point, what are you really trying to achieve here?
To the "abstract property" example, I don't think the analogy with the
CFG quite holds because that is about analyses, unlike our situation.
In our use case, there are two passes modifying the IR to establish
what one might think of as different "normal forms", and we want to
express the fact that those are compatible and can both be established
simultaneously. So they are conceptually quite different things.
Note that this directly interacts with the linking question. If you
have two passes each establishing a kind of normal form, and they are
compatible with each other, then beyond the minimal change I've put on
Phabricator which is the bare minimum to make our use case work, you
quite likely want to say that they preserve each other in many cases,
in which case the linker requirement would cause a cyclical dependency
that breaks everything.
As an additional food for thought, I've also started to wonder if we'd
even be able to express this kind of dependency in the non-legacy pass
manager. Is this something we _want_ to be able to express in the pass
manager?
Cheers,
Nicolai