<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi guys,<br>
<br>
Am 27.07.2013 10:56, schrieb Andrew Trick:<br>
</div>
<blockquote
cite="mid:BA7ADEED-0E20-466B-BECC-0CA1A8144E63@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Jul 27, 2013, at 1:30 AM, Chandler Carruth <<a
moz-do-not-send="true" href="mailto:chandlerc@google.com">chandlerc@google.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Jul 27, 2013 at 1:07 AM,
Andrew Trick <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:atrick@apple.com" target="_blank"
class="cremed">atrick@apple.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="im">
<blockquote type="cite">
<div style="word-wrap:break-word">
<div>(1) In terms of code organization, these
anti-canonical, target-selected transforms
should live somewhere else. I kept quiet
becase I hadn't come up with an alternative,
but we can do that now. OptimizeCFG.cpp?</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>It would be even more self-evident to group all
of these type of branch avoidance utils into a
FlattenCFG package. So I'm changing my vote to
FlattenCFG.cpp.</div>
</blockquote>
</div>
<br>
To focus on the immediate issue: I agree.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Design wise, I would suggest one
step further: I think that CFG-flattening of this form is
somewhat specialized and we should just build a nice
specialized set of optimizations targetting that use case,
and have the targets add those passes from their target
machine rather than monkey with the general purpose PMB.
We can't easily get this right in the PMB because of the
silly way CGSCC stuff is defined, and I think that this is
likely to be best as a late-stage CFG pass anyways not
unlike LSR, etc. I'm not sure that it really has anything
to do with SimplifyCFG (or OptimizeCFG, which I've begun
to think is somewhat likely to make more sense in MI w/
register pressure and critical path info). So, my vote is
for a more targeted tool in the toolbox.</div>
</div>
</blockquote>
</div>
<br>
<div>Mei,</div>
<div><br>
</div>
<div>You seem to have a reason for running SimplifyParallelAndOr
after the basic cleanup transforms but before branch
simplification. Whereas MergeIfRegion runs only after all other
simplifications. That does seem intuitive to me, but I wonder if
it is absolutely necessary. Can you illustrate with an example
or two why the simplifications need to be interleaved this way?
Are you just trying to avoid the need for another round of
iteration in the SimplifyCFGPass driver? I think the direction
of design refactoring depends on it.</div>
<div><br>
</div>
</blockquote>
<br>
I strongly agree with Chandlers opinion that those target dependent
optimization passes shouldn't be added by any target independent
pass manager.<br>
<br>
I haven't followed the full discussion, but to me it looked like one
of the main arguments against running those passes later were
concerns about the compile time because additional to those CFG
modifications the R600 target also requires that we inline ALL
functions. This inlining of all functions is necessary because the
R600 architecture doesn't have a conventional stack and so can't
make most kind of subroutine calls.<br>
<br>
I strongly suspect that this (target specific) inlining of all
functions is done by the target independent function inliner using
something like the "always inline" flag on every function or
something like this.<br>
<br>
I just wanted to note that doing it like this is actually a bit
wrong, cause we are using a target independent optimization feature
to fulfill our target dependent requirements. The better approach
would be to inline all functions in a target specific pass right
after the target specific optimizations and before CFG
structurization and code generation.<br>
<br>
This would also allow us to handle things like inlining of recursive
function, which is necessary for R600 but also something no halve
way sane target independent optimizer would do.<br>
<br>
Just some thoughts about this topic,<br>
Christian. <br>
<br>
<blockquote
cite="mid:BA7ADEED-0E20-466B-BECC-0CA1A8144E63@apple.com"
type="cite">
<div>-Andy</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
</body>
</html>