<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 27, 2013 at 5:15 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> >>> So I second Duncan's idea that we should have control over<br>

> >> optimization<br>
> >>> level. Here's the thing: we already have detailed control over the<br>
> >>> IR-level optimizations. We can run PassManagers over particular<br>
> >>> functions, choose the particular pipeline, etc. I think that should<br>
> be<br>
> >>> enough, or should be extended. The existing API for this doesn't use<br>
> >>> function attributes, and I think the natural extension wouldn't<br>
> >> either.<br>
> >><br>
> >> Hmm, by "we" do you actually mean "clang but not opt or any other<br>
> tool"<br>
> >> here?<br>
><br>
> I was referring to clang, or to your frontend if you have one.<br>
><br>
>    Some of us were chatting about this stuff yesterday and thought<br>
> >> that while the PassManager manipulation idea would work for clang it<br>
> >> wouldn't generalize to other tools.  This suggests that optnone<br>
> really<br>
> >> does need to be an IR attribute.  (I could easily be wrong, I don't<br>
> >> really understand this PassManager stuff.)<br>
><br>
> Opt offers control of the passmanager all the way out to the<br>
> command-line. It currently doesn't offer per-function control, but you<br>
> can do the same things with the existing command-line tools if you<br>
> really wanted. Use llvm-extract to pull out the functions, then opt,<br>
> then llvm-link to merge them back in.<br>
><br>
> I don't understand why you think it would need to be an IR attribute<br>
> just because the other tools wouldn't "support" it. There are plenty<br>
> language attributes in clang which aren't represented in the IR (and<br>
> hence not supported there).<br>
><br>
> It's also difficult to describe what goes wrong with having an optnone<br>
> attribute. There are some questions that are hard to answer, like "what<br>
> about module passes?" which I claim is a symptom of this having the<br>
> wrong design. It's very clear what happens with module passes when you<br>
> use the API directly.<br>
><br>
> Mostly I just don't like the idea of replicating "mechanism to control<br>
> passmanager" in the IR. We already have a mechanism to control the<br>
> passmanager, and this new one doesn't fit. If the passmanager currently<br>
> took the list of passes to run as a module attribute, I wouldn't be so<br>
> bothered.<br>
><br>
> Nick<br>
<br>
</div></div>I hadn't looked closely at the pass manager previously but this morning<br>
I spent some time with it.  Now I understand why you're proposing<br>
what you do--because this pass-management interface MAKES NO SENSE.<br>
<br>
The front end has no business knowing the names and reasonable sets of<br>
optimization and codegen passes.  The four other compiler systems I've<br>
worked with previously all had the frontend provide the moral equivalent<br>
of command-line options and left these details up to the middle/backend.<br>
I had naively assumed that Clang/LLVM would use this sensible design too.<br>
So much attention to good structure, not to mention layering, throughout<br>
the project; and here's this-- this-- gah!<br></blockquote><div><br></div><div>Remember that LLVM serves a wider variety of use cases than just being a "compiler backend".</div><div><br></div><div>I think that historically Clang has been so tightly coupled to LLVM that it has just been easier to directly use the "low level" pass management API. Without having a larger number of production-quality language frontends actively participating in LLVM development (most just take LLVM as it is, and report a couple bugs here and there), it's hard to pin down what a higher-level API should look like that would best serve frontends.</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Okay... deep breaths... ommmmm...<br>
<br>
What we proposed would make sense if this aspect of the Clang/LLVM<br>
interface had a reasonable, or even rational, division of responsibility.<br>
Now I don't know what to think.<br>
<br>
--paulr<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 27, 2013 at 5:15 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> >>> So I second Duncan's idea that we should have control over<br>

> >> optimization<br>
> >>> level. Here's the thing: we already have detailed control over the<br>
> >>> IR-level optimizations. We can run PassManagers over particular<br>
> >>> functions, choose the particular pipeline, etc. I think that should<br>
> be<br>
> >>> enough, or should be extended. The existing API for this doesn't use<br>
> >>> function attributes, and I think the natural extension wouldn't<br>
> >> either.<br>
> >><br>
> >> Hmm, by "we" do you actually mean "clang but not opt or any other<br>
> tool"<br>
> >> here?<br>
><br>
> I was referring to clang, or to your frontend if you have one.<br>
><br>
>    Some of us were chatting about this stuff yesterday and thought<br>
> >> that while the PassManager manipulation idea would work for clang it<br>
> >> wouldn't generalize to other tools.  This suggests that optnone<br>
> really<br>
> >> does need to be an IR attribute.  (I could easily be wrong, I don't<br>
> >> really understand this PassManager stuff.)<br>
><br>
> Opt offers control of the passmanager all the way out to the<br>
> command-line. It currently doesn't offer per-function control, but you<br>
> can do the same things with the existing command-line tools if you<br>
> really wanted. Use llvm-extract to pull out the functions, then opt,<br>
> then llvm-link to merge them back in.<br>
><br>
> I don't understand why you think it would need to be an IR attribute<br>
> just because the other tools wouldn't "support" it. There are plenty<br>
> language attributes in clang which aren't represented in the IR (and<br>
> hence not supported there).<br>
><br>
> It's also difficult to describe what goes wrong with having an optnone<br>
> attribute. There are some questions that are hard to answer, like "what<br>
> about module passes?" which I claim is a symptom of this having the<br>
> wrong design. It's very clear what happens with module passes when you<br>
> use the API directly.<br>
><br>
> Mostly I just don't like the idea of replicating "mechanism to control<br>
> passmanager" in the IR. We already have a mechanism to control the<br>
> passmanager, and this new one doesn't fit. If the passmanager currently<br>
> took the list of passes to run as a module attribute, I wouldn't be so<br>
> bothered.<br>
><br>
> Nick<br>
<br>
</div></div>I hadn't looked closely at the pass manager previously but this morning<br>
I spent some time with it.  Now I understand why you're proposing<br>
what you do--because this pass-management interface MAKES NO SENSE.<br>
<br>
The front end has no business knowing the names and reasonable sets of<br>
optimization and codegen passes.  The four other compiler systems I've<br>
worked with previously all had the frontend provide the moral equivalent<br>
of command-line options and left these details up to the middle/backend.<br>
I had naively assumed that Clang/LLVM would use this sensible design too.<br>
So much attention to good structure, not to mention layering, throughout<br>
the project; and here's this-- this-- gah!<br>
<br>
Okay... deep breaths... ommmmm...<br>
<br>
What we proposed would make sense if this aspect of the Clang/LLVM<br>
interface had a reasonable, or even rational, division of responsibility.<br>
Now I don't know what to think.<br>
<br>
--paulr<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>