[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