Xiang Gao
2015-Mar-18 17:12 UTC
[LLVMdev] Implementing if-conversion as a GSoC 2015 project?
OK, Let me describe. There is nothing wrong with if-conversion in LLVM. The
algorithm implemented in LLVM can handle the if(???){do something} and
if(???){do something}else{do something else} case very well. But it can
handle complicated case like when there are a lot of gotos in the program.
The more systematic way to do if-conversion is based on Hyperblock [Scott
A. Mahlke et al 1992]
<http://www.eecs.umich.edu/eecs/about/articles/2015/p45-mahlke.pdf>, which
is set of basic blocks with one entrance and one or more exits. The
algorithms now implemented in LLVM is very easy to understand, and very
easy to implement. But it is not general, and it might not generate code
with best efficient.
As we know, if-conversion is a double-edged sword, it might increase the
efficiency, it might also make it worse. For example, if the program to be
compiled have a code like:
if (<a>) {
execute 1000 statements
} else {
execute 1 statements
}
In the case when <a> is almost always true, it is very efficient because
it
avoid branching with only executing one more statement as punishment. The
improvements of performance from eliminating the branching is always larger
than 1 cpu cycle. However, in the case when <a> is almost always false,
doing if-conversion is a stupid decision because the improvements of
eliminating the branch is very limited here, but the punish, that 1000 more
statements have to be executed everytime, really hurt.
There are studies on how to make a balance in whether to do if-conversion
or not. There are both static policy [David I. August et al 1997]
<http://impact.crhc.illinois.edu/shared/papers/micro-97-framework.pdf> and
dynamic policy [Kim M. Hazelwood and Thomas Conte 2000]
<http://www.cs.virginia.edu/kim/docs/pact00.pdf>. What I want to do for
GSoC is to implement these approaches into LLVM.
Xiang Gao
2015-03-17 18:14 GMT-04:00 John Criswell <jtcriswel at gmail.com>:
> Dear Xiang,
>
> Can you briefly describe the limitations with the current if-conversion in
> LLVM and how you plan to improve it? I haven't read your thesis, and I
> (and others) are unlikely to have time to do so.
>
> Regards,
>
> John Criswell
>
>
> On 3/16/15 4:23 PM, Xiang Gao wrote:
>
> Hi,
>
> Are you guys interested in implementing if-conversion as a GSoC 2015
> project? Last year, I did a literature review about approaches of
> if-conversion and the if-conversion in LLVM. This was the undergraduate
> thesis of my bachelor degree. It seems that, the if-conversion used in LLVM
> is a very simple approach instead of following the literature. So I want to
> implement the approaches in the literature in LLVM and get support from
> Google for this. Are you guys interested?
>
> Best,
>
> Xiang Gao
>
>
> _______________________________________________
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu
http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> --
> John Criswell
> Assistant Professor
> Department of Computer Science, University of
Rochesterhttp://www.cs.rochester.edu/u/criswell
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150318/fc51ee79/attachment.html>
Evan Cheng
2015-Mar-18 18:20 UTC
[LLVMdev] Implementing if-conversion as a GSoC 2015 project?
> On Mar 18, 2015, at 10:12 AM, Xiang Gao <qasdfgtyuiop at gmail.com> wrote: > > OK, Let me describe. There is nothing wrong with if-conversion in LLVM. The algorithm implemented in LLVM can handle the if(???){do something} and if(???){do something}else{do something else} case very well. But it can handle complicated case like when there are a lot of gotos in the program. The more systematic way to do if-conversion is based on Hyperblock [Scott A. Mahlke et al 1992] <http://www.eecs.umich.edu/eecs/about/articles/2015/p45-mahlke.pdf>, which is set of basic blocks with one entrance and one or more exits. The algorithms now implemented in LLVM is very easy to understand, and very easy to implement. But it is not general, and it might not generate code with best efficient.Questions: * You are not going to get good performance out of hyperblock without global scheduling. Are you planning to adopt the MI schedule to handle HB? Will it be predicate aware? * What architecture are you targeting? HB makes more sense for ISA with lots of predicated registers. Evan> > As we know, if-conversion is a double-edged sword, it might increase the efficiency, it might also make it worse. For example, if the program to be compiled have a code like: > if (<a>) { > execute 1000 statements > } else { > execute 1 statements > } > In the case when <a> is almost always true, it is very efficient because it avoid branching with only executing one more statement as punishment. The improvements of performance from eliminating the branching is always larger than 1 cpu cycle. However, in the case when <a> is almost always false, doing if-conversion is a stupid decision because the improvements of eliminating the branch is very limited here, but the punish, that 1000 more statements have to be executed everytime, really hurt. > > There are studies on how to make a balance in whether to do if-conversion or not. There are both static policy [David I. August et al 1997] <http://impact.crhc.illinois.edu/shared/papers/micro-97-framework.pdf> and dynamic policy [Kim M. Hazelwood and Thomas Conte 2000] <http://www.cs.virginia.edu/kim/docs/pact00.pdf>. What I want to do for GSoC is to implement these approaches into LLVM. > > Xiang Gao > > 2015-03-17 18:14 GMT-04:00 John Criswell <jtcriswel at gmail.com <mailto:jtcriswel at gmail.com>>: > Dear Xiang, > > Can you briefly describe the limitations with the current if-conversion in LLVM and how you plan to improve it? I haven't read your thesis, and I (and others) are unlikely to have time to do so. > > Regards, > > John Criswell > > > On 3/16/15 4:23 PM, Xiang Gao wrote: >> Hi, >> >> Are you guys interested in implementing if-conversion as a GSoC 2015 project? Last year, I did a literature review about approaches of if-conversion and the if-conversion in LLVM. This was the undergraduate thesis of my bachelor degree. It seems that, the if-conversion used in LLVM is a very simple approach instead of following the literature. So I want to implement the approaches in the literature in LLVM and get support from Google for this. Are you guys interested? >> >> Best, >> >> Xiang Gao >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochester > http://www.cs.rochester.edu/u/criswell <http://www.cs.rochester.edu/u/criswell> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150318/2b4c51ac/attachment.html>
Gerolf Hoflehner
2015-Mar-18 18:49 UTC
[LLVMdev] Implementing if-conversion as a GSoC 2015 project?
It would help most if you had key examples/benchmarks where if conversion will provide (additional) performance benefits. Literature is a limited guide. For example, in hindsight many early papers on Itanium oversold the potential benefits - which is not necessarily their fault: branch predictors got better over time, global scheduling techniques improved over time etc. In the specific example of the Mahlke paper if-conversion turned out to improve global scheduling in their compiler. With a better global scheduler the result is different. When you scope the design it will be helpful when the pass can be invoked on demand for a region by loop transformations and in the codegen. Specific example where if conversion enables e.g. vectorization or can eliminate targeted data dependent branches (on top of what can be done today) is where I think the benefits will be. The more specific examples you have the less likely you’ll get lost in the morass of compiler changes that get triggered by the ‘advanced’ conversion schemes. -Gerolf> On Mar 18, 2015, at 11:20 AM, Evan Cheng <evan.cheng at apple.com> wrote: > >> >> On Mar 18, 2015, at 10:12 AM, Xiang Gao <qasdfgtyuiop at gmail.com <mailto:qasdfgtyuiop at gmail.com>> wrote: >> >> OK, Let me describe. There is nothing wrong with if-conversion in LLVM. The algorithm implemented in LLVM can handle the if(???){do something} and if(???){do something}else{do something else} case very well. But it can handle complicated case like when there are a lot of gotos in the program. The more systematic way to do if-conversion is based on Hyperblock [Scott A. Mahlke et al 1992] <http://www.eecs.umich.edu/eecs/about/articles/2015/p45-mahlke.pdf>, which is set of basic blocks with one entrance and one or more exits. The algorithms now implemented in LLVM is very easy to understand, and very easy to implement. But it is not general, and it might not generate code with best efficient. > > Questions: > > * You are not going to get good performance out of hyperblock without global scheduling. Are you planning to adopt the MI schedule to handle HB? Will it be predicate aware? > * What architecture are you targeting? HB makes more sense for ISA with lots of predicated registers. > > Evan > >> >> As we know, if-conversion is a double-edged sword, it might increase the efficiency, it might also make it worse. For example, if the program to be compiled have a code like: >> if (<a>) { >> execute 1000 statements >> } else { >> execute 1 statements >> } >> In the case when <a> is almost always true, it is very efficient because it avoid branching with only executing one more statement as punishment. The improvements of performance from eliminating the branching is always larger than 1 cpu cycle. However, in the case when <a> is almost always false, doing if-conversion is a stupid decision because the improvements of eliminating the branch is very limited here, but the punish, that 1000 more statements have to be executed everytime, really hurt. >> >> There are studies on how to make a balance in whether to do if-conversion or not. There are both static policy [David I. August et al 1997] <http://impact.crhc.illinois.edu/shared/papers/micro-97-framework.pdf> and dynamic policy [Kim M. Hazelwood and Thomas Conte 2000] <http://www.cs.virginia.edu/kim/docs/pact00.pdf>. What I want to do for GSoC is to implement these approaches into LLVM. >> >> Xiang Gao >> >> 2015-03-17 18:14 GMT-04:00 John Criswell <jtcriswel at gmail.com <mailto:jtcriswel at gmail.com>>: >> Dear Xiang, >> >> Can you briefly describe the limitations with the current if-conversion in LLVM and how you plan to improve it? I haven't read your thesis, and I (and others) are unlikely to have time to do so. >> >> Regards, >> >> John Criswell >> >> >> On 3/16/15 4:23 PM, Xiang Gao wrote: >>> Hi, >>> >>> Are you guys interested in implementing if-conversion as a GSoC 2015 project? Last year, I did a literature review about approaches of if-conversion and the if-conversion in LLVM. This was the undergraduate thesis of my bachelor degree. It seems that, the if-conversion used in LLVM is a very simple approach instead of following the literature. So I want to implement the approaches in the literature in LLVM and get support from Google for this. Are you guys interested? >>> >>> Best, >>> >>> Xiang Gao >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> >> >> -- >> John Criswell >> Assistant Professor >> Department of Computer Science, University of Rochester >> http://www.cs.rochester.edu/u/criswell <http://www.cs.rochester.edu/u/criswell> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150318/f56473a5/attachment.html>