[llvm-dev] Visitation of declarations in FunctionAtrs with new and old pass managers?

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 12 11:57:17 PDT 2021


Arthur,

On 4/10/21 11:39 PM, Arthur Eubanks wrote:
> I think it makes more sense to do something like that in a pass 
> like InferFunctionAttrsPass.
InferFunctionAttrs is currently a module pass and appears to be 
scheduled well before the CGSCC pass walk.  I agree that we could add 
this logic there and get consistent behavior between the two pass 
managers.  I'm a bit hesitant about having the logic for inference in 
two different places, but thinking about it, this doesn't seem too bad.
> We should decide to visit declarations consistently with function pass 
> managers, which currently don't visit declarations.
I couldn't parse this statement, can you rephrase?

> Adding declarations to the new PM CGSCC infra would add complexity and 
> passes would have to check if they're working with a declaration vs 
> definition.

Right, but wasn't that the behavior of the old pass manager? This 
doesn't seem like a bad behavior tbh.  I'm mostly curious to know if it 
was a conscious decision to change behavior, or not.

Philip

>
> On Fri, Apr 9, 2021 at 1:41 PM Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     I ran across a dependency in the way the new and old pass managers
>     interact with function-attrs.  I'm not sure whether this is expected
>     behavior or not, but with some digging, I couldn't find a clear
>     motivation.  Anyone have context on this?
>
>     Essentially, under the old pass manager, FunctionAttrs appears to
>     visit
>     declarations, and under the new one, it doesn't.   Here's an example
>     that shows how this can change the output of function-attrs:
>
>     $ cat decl.ll
>
>     declare void @readnone() readnone
>
>     $ ./opt -S -function-attrs decl.ll -enable-new-pm=1
>     ; ModuleID = 'decl.ll'
>     source_filename = "decl.ll"
>
>     ; Function Attrs: readnone
>     declare void @readnone() #0
>
>     attributes #0 = { readnone }
>
>     $ ./opt -S -function-attrs decl.ll -enable-new-pm=0
>     ; ModuleID = 'decl.ll'
>     source_filename = "decl.ll"
>
>     ; Function Attrs: nofree nosync readnone
>     declare void @readnone() #0
>
>     attributes #0 = { nofree nosync readnone }
>
>     (The example uses nofree and nosync, but please don't focus on the
>     semantics of those attributes.  That's a separate discussion.)
>
>     To me, it seems odd to not have declarations be SCCs of their own,
>     and
>     thus passed to function-attrs.  Does anyone have a good
>     explanation for
>     why we made this change?  And in particular, what the "right" way of
>     inferring attributes for a partially annotated declaration might
>     be in
>     our new world?
>
>     Philip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210412/a75d7d2e/attachment.html>


More information about the llvm-dev mailing list