Hello everyone, If you've read through my previous introduction email (http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html), you can safely ignore this message. The short story is: CFL-AA does not seem to be broken anymore. Please try it out and help us find more bugs / performance issues if switching to it in the future sounds interesting to you. Here are more backgrounds: I was working on a GSoC project, whose first step is to fix cfl-aa. After a bug was patched up in r268269, bootstrapping llvm+clang with standalone cfl-aa as well as cfl-aa+basicaa breaks nothing in llvm test-suite. It shows that cfl-aa is in a pretty good shape today and are almost ready to be turned out by default. But before we can do this, we'd like to gather enough evidences that it is a safe move. A more thorough description of the current status can be found in the link provided at the beginning of this message. To compile your codes with cfl-aa turned on, simply add " -mllvm -use-cfl-aa -mllvm -use-cfl-aa-in-codegen" option to the clang command line arguments. -- Best Regards, -- Jia Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160516/541901ca/attachment.html>
Hi Jia, We did some testing with CFL-AA enabled on an aarch64 OoO target on the llvm test-suite and SPEC (with and without LTO). We didn't observe any correctness issues. We didn't really observe any positive or negative performance differences, other than a single llvm test llvm-test-suite/SingleSource/Benchmarks/Shootout/lists that improved ~3%. I also looked over some of the generated code differences: only a handful of tests changed at all (9 in llvm test-suite, 5 in SPEC2006), and in most of these only a few functions changed, usually with a small amount of static instruction differences. We didn't collect any compile time data. -Geoff On 5/16/2016 5:19 PM, Jia Chen via llvm-dev wrote:> Hello everyone, > > If you've read through my previous introduction email > (http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html), you > can safely ignore this message. > > The short story is: CFL-AA does not seem to be broken anymore. Please > try it out and help us find more bugs / performance issues if > switching to it in the future sounds interesting to you. > > Here are more backgrounds: I was working on a GSoC project, whose > first step is to fix cfl-aa. After a bug was patched up in r268269, > bootstrapping llvm+clang with standalone cfl-aa as well as > cfl-aa+basicaa breaks nothing in llvm test-suite. It shows that cfl-aa > is in a pretty good shape today and are almost ready to be turned out > by default. But before we can do this, we'd like to gather enough > evidences that it is a safe move. A more thorough description of the > current status can be found in the link provided at the beginning of > this message. > > To compile your codes with cfl-aa turned on, simply add " -mllvm > -use-cfl-aa -mllvm -use-cfl-aa-in-codegen" option to the clang command > line arguments. > -- > Best Regards, > > -- > Jia Chen > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Geoff Berry Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160519/cf0597b5/attachment.html>
Hi Geoff, Thank you so much for the effort! It's good to hear that cfl-aa didn't break anything. However, the fact that it doesn't quite affect code generation is also concerning. I'll definitely look into the issue. On 05/19/2016 02:03 PM, Geoff Berry wrote:> Hi Jia, > > We did some testing with CFL-AA enabled on an aarch64 OoO target on the > llvm test-suite and SPEC (with and without LTO). We didn't observe any > correctness issues. We didn't really observe any positive or negative > performance differences, other than a single llvm test > llvm-test-suite/SingleSource/Benchmarks/Shootout/lists that improved > ~3%. I also looked over some of the generated code differences: only a > handful of tests changed at all (9 in llvm test-suite, 5 in SPEC2006), > and in most of these only a few functions changed, usually with a small > amount of static instruction differences. We didn't collect any compile > time data. > > -Geoff > > On 5/16/2016 5:19 PM, Jia Chen via llvm-dev wrote: >> Hello everyone, >> >> If you've read through my previous introduction email >> (http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html), you >> can safely ignore this message. >> >> The short story is: CFL-AA does not seem to be broken anymore. Please >> try it out and help us find more bugs / performance issues if >> switching to it in the future sounds interesting to you. >> >> Here are more backgrounds: I was working on a GSoC project, whose >> first step is to fix cfl-aa. After a bug was patched up in r268269, >> bootstrapping llvm+clang with standalone cfl-aa as well as >> cfl-aa+basicaa breaks nothing in llvm test-suite. It shows that cfl-aa >> is in a pretty good shape today and are almost ready to be turned out >> by default. But before we can do this, we'd like to gather enough >> evidences that it is a safe move. A more thorough description of the >> current status can be found in the link provided at the beginning of >> this message. >> >> To compile your codes with cfl-aa turned on, simply add " -mllvm >> -use-cfl-aa -mllvm -use-cfl-aa-in-codegen" option to the clang command >> line arguments. >> -- >> Best Regards, >> >> -- >> Jia Chen >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > Geoff Berry > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >-- Best Regards, -- Jia Chen Department of Computer Science University of Texas at Austin jchen at cs.utexas.edu