Arthur Eubanks via llvm-dev
2021-Apr-11 06:39 UTC
[llvm-dev] Visitation of declarations in FunctionAtrs with new and old pass managers?
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>
Johannes Doerfert via llvm-dev
2021-Apr-11 15:47 UTC
[llvm-dev] Visitation of declarations in FunctionAtrs with new and old pass managers?
Passes had to check declaration vs. definition before, I don't think that is the most important argument. That said, there is only so much you can do for declarations anyway. My proposal would be, as might have been expected, to run a On 4/11/21 1:39 AM, Arthur Eubanks wrote:> 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 >> >>
Johannes Doerfert via llvm-dev
2021-Apr-11 15:54 UTC
[llvm-dev] Visitation of declarations in FunctionAtrs with new and old pass managers?
Passes had to deal with Decl. vs Def. before and they managed. That said, there is only that much you can do with declarations and I would suggest we do it early as part of a module pass. Attributor run early as module pass will right now *not* annotate the declaration but still derive the information for the call sites: https://godbolt.org/z/b9a8Gheqb We could make it annotate declarations as well with little effort. ~ Johannes On 4/11/21 1:39 AM, Arthur Eubanks wrote:> 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 >> >>
Philip Reames via llvm-dev
2021-Apr-12 18:57 UTC
[llvm-dev] Visitation of declarations in FunctionAtrs with new and old pass managers?
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>