[llvm-dev] Visitation of declarations in FunctionAtrs with new and old pass managers?
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 13 09:24:28 PDT 2021
On 4/13/21 12:19 AM, Arthur Eubanks wrote:
>
>> The new PM CGSCC infra assumes that only calls to known library
>> functions can be introduced out of thin air. So we shouldn't be
>> introducing arbitrary declarations in a CGSCC pipeline (just
>> intrinsics and library functions I believe).
>> I suppose it's possible to introduce a call to an arbitrary
>> function in some module pass, but that seems out of the ordinary.
>
> How does this connect? Everything you said parses; I just don't
> see how this is connected to the topic of this thread.
>
> Sorry, my point was that having an early module pass to infer
> attributes on existing declarations should be sufficient, we shouldn't
> have to worry about doing that again later on in the pipeline.
Ah, I see. In theory, I agree.
In practice, I see some pragmatic issues. The main concern I have is
that new declarations of intrinsics or "known functions" aren't
annotated inside the CGSCC iteration. At the moment, that is only done
by the previous module pass. As a result, if some transform replaces a
call from one intrinsic with a call to a "known function" with more
restrictive memory semantics (say), then we will not be able to infer
the more restrictive semantics for the caller of the intrinsic in the
same CGSCC pass.
I don't know how much that hurts, but it seems like we're missing some
opportunities here, solely because we chose to not visit declarations.
To avoid confusion, let me clarify that this is not a difference in
behavior with the old pass manager. It had the same problem as well.
This particular issue is related but distinct from the one I started the
thread about (which is inferring attributes from each other on non-known
functions.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210413/0d999b6d/attachment.html>
More information about the llvm-dev
mailing list