llvm dev - Apr 2021 - Visitation of declarations in FunctionAtrs with new and old pass managers?

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

I think it makes more sense to do something like that in a pass
like InferFunctionAttrsPass. We should decide to visit declarations
consistently with function pass managers, which currently don't visit
declarations. 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.

On Fri, Apr 9, 2021 at 1:41 PM Philip Reames <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/20210410/a77f559f/attachment.html>