<div dir="ltr">On 21 June 2013 06:38, Ye, Mei <span dir="ltr"><<a href="mailto:Mei.Ye@amd.com" target="_blank">Mei.Ye@amd.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">






<div lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div>
<p class=""><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">This transformation reduces branches.  It can benefit architectures with deep pipelines, less powerful branch predictors, or branch divergence on GPUs.</span> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">I did have a GPU benchmark that shows roughly 1.5X performance improvement.</span></p>
</div></div></blockquote><div><br></div><div style>That is a big improvement on a specific benchmark on a very narrow category of targets. I share Evan's concerns, as quite often what's good for GPUs is not for CPUs and vice versa.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div>
<p class=""><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">But on the other hand, there is probably very few optimizations that can benefit all architectures.  And it is also unrealistic to have performance measurement
 on all architectures to justify an optimization item.    What I am seeing is that compiler vendors have a tendency to push codes into their target space as much as possible, often at the expense of code quality that minimizes code-sharing and increases compilation
 time.   </span></p></div></div></blockquote><div><br></div><div style>Indeed, and it's the job of the maintainers to make sure they get laid down properly. As it stands, I think it could bring more harm than good, and you haven't provided much information to say otherwise.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div><p class=""><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">There is definitely a need to enable target-specific tuning in machine-independent optimizations.  Is there a guide line on a good approach to do this?  I have
 seen some cases that rely on threshold tuning, which can be non-deterministic and therefore unreliable.</span></p></div></div></blockquote><div><br></div><div>Normally what people do is to add it as a pass, add a flag disabled by default, and use it on their specific problems. If more and more people find it useful, some targets or special configurations can turn it on by default on front-ends, or when special configurations are found (ex. when NEON/SSE is present and the pipeline is this or that way).<br>
</div><div><br></div><div style>Whatever you add by default has to be proven beneficial on *most* configurations of *most* targets, not on a single GPU implementation. When that happens, you normally see an improvement of 1% or less, not 50%, but what matters more is that there are no regressions in performance. If there is, it can't be enabled by default.</div>
<div style><br></div><div style>cheers,</div><div style>--renato</div></div></div></div>