On 6 November 2012 14:53, Duncan Sands <baldrick at free.fr> wrote:> Hi Anitha, > > > On 05/11/12 10:29, Anitha Boyapati wrote: > >> >> >> On 5 November 2012 14:32, Duncan Sands <baldrick at free.fr >> <mailto:baldrick at free.fr>> wrote: >> >> Hi Anitha, >> >> >> http://llvm.org/bugs/show_bug.**__cgi?id=14185<http://llvm.org/bugs/show_bug.__cgi?id=14185> >> >> <http://llvm.org/bugs/show_**bug.cgi?id=14185<http://llvm.org/bugs/show_bug.cgi?id=14185> >> > >> I am stuck on analysis. Does any one have alternate suggestions >> on debugging >> llvm? (Please refer to comments for the work done so far) >> >> >> try to reduce a small standalone testcase which is an LLVM IR (.ll) >> file >> >> Yes. Unfortunately, that is the challenge at the moment. >> > > did you reduce everything down to one problematic source file? If so, you > can > then start moving stuff out of that file to an auxiliary file until you > only > have left a minimal core that shows the problem. But maybe you did that > already? >I could corner down the segfault to a single function in source file. But the problem is - if that function is responsible for segfault or if it is the optimization somewhere else that is driving the segfault. In the worst case it could be so. I am yet to dive deeper there. Meanwhile, I have some question w.r.t "-fplugin-arg-dragonegg-emit-ir". Lets say I use the following command: [1]. g++ -O2 -march=bdver2 fplugin=dragonegg.so -mno-fma -mfma4 -fplugin-arg-dragonegg-emit-ir -S -ffast-math <test.c> -o <test.ll> Does the above command produce an IR that is already optimized because of "-O2 -ffast-math -mno-fma -mfma4" ? [2]. If I feed the above generated <test.ll> to clang as follows: clang -O3 -march=bdver2 -mno-fma -mfma4 -ffp-contract=fast <test.ll> Does clang proceed to optimize the test.ll w.r.t "-O3 -ffp-contract=fast -mno-fma -mfma4" ? (I am not sure if -ffp-contract=fast has any effect there, but I could be wrong though) Also thanks for the immediate fix for __builtin_iceil(). I can see that the issue got resolved. -Anitha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121107/ed76f912/attachment.html>
Hi Anitha,> http://llvm.org/bugs/show_bug.____cgi?id=14185 > <http://llvm.org/bugs/show_bug.__cgi?id=14185> > > <http://llvm.org/bugs/show___bug.cgi?id=14185 > <http://llvm.org/bugs/show_bug.cgi?id=14185>> > I am stuck on analysis. Does any one have alternate suggestions > on debugging > llvm? (Please refer to comments for the work done so far) > > > try to reduce a small standalone testcase which is an LLVM IR (.ll) > file > > Yes. Unfortunately, that is the challenge at the moment. > > > did you reduce everything down to one problematic source file? If so, you can > then start moving stuff out of that file to an auxiliary file until you only > have left a minimal core that shows the problem. But maybe you did that > already? > > I could corner down the segfault to a single function in source file. But the > problem is - if that function is responsible for segfault or if it is the > optimization somewhere else that is driving the segfault. In the worst case > it could be so. I am yet to dive deeper there.you should try to determine which compilation stage introduces the segmentation fault (optimizers, codegen?). It sounds like you are trying to do so already, more comments below.> Meanwhile, I have some question w.r.t "-fplugin-arg-dragonegg-emit-ir". Lets say > I use the following command: > [1]. g++ -O2 -march=bdver2 fplugin=dragonegg.so -mno-fma -mfma4 > -fplugin-arg-dragonegg-emit-ir -S -ffast-math <test.c> -o <test.ll> > Does the above command produce an IR that is already optimized because of "-O2 > -ffast-math -mno-fma -mfma4" ?Yes, it produces optimized IR due to -O2. If you want unoptimized IR then add -fplugin-arg-dragonegg-llvm-ir-optimize=0 That way the output should be exactly the same as the output dragonegg would normally run the LLVM optimizers on, e.g. GCC constant folding and other such optimizations which get turned on at -O2 will still have happened (dragonegg turns off almost all GCC optimizations by default, but turning everything off isn't practical). Running the output through "opt -O2" should then do the same optimizations as dragonegg would have done. I say "should" because in my experience this isn't always true, though it is supposed to be true. Next comes the codegen stage, which you can emulate using llc (or clang like you do below, but llc is more direct). It isn't that easy finding out exactly what flags dragonegg passes to llc, so this might be a bit painful.> [2]. If I feed the above generated <test.ll> to clang as follows: > clang -O3 -march=bdver2 -mno-fma -mfma4 -ffp-contract=fast <test.ll> > Does clang proceed to optimize the test.ll w.r.t "-O3 -ffp-contract=fast > -mno-fma -mfma4" ? (I am not sure if -ffp-contract=fast has any effect there, > but I could be wrong though)I don't know. You can always run it with and without -O3 to see if the output changes. Likewise for the other options. The advantage of using llc is that you have a better idea what is being done.> Also thanks for the immediate fix for __builtin_iceil(). I can see that the > issue got resolved.Thanks for confirming. Ciao, Duncan.
On 7 November 2012 15:29, Duncan Sands <baldrick at free.fr> wrote:> I could corner down the segfault to a single function in source file. But >> the >> problem is - if that function is responsible for segfault or if it is the >> optimization somewhere else that is driving the segfault. In the worst >> case >> it could be so. I am yet to dive deeper there. >> > > you should try to determine which compilation stage introduces the > segmentation > fault (optimizers, codegen?). It sounds like you are trying to do so > already, > more comments below. > >One of the many combinations that gives me some clue that Code Generation (or optimizations during CodeGen) is going wrong. I have compiled the problematic function with DragonEgg to emit llvm IR (say test.ll). This is now fed to llc as follows: Original Buggy Case: [Turns off FMA3, Turns on FMA4] llc -fp-contract=fast -O0 -mcpu=bdver2 -mattr=-fma,+fma4 test.ll -o ComputeNonbondedUtil.s Correct Case: [Turns on FMA3] llc -fp-contract=fast -O0 -mcpu=bdver2 -mattr=+fma test.ll -o ComputeNonbondedUtil.s Then compiled and linked as usual with clang. The first case where FMA4 is turned on reproduces the bug even though -O0 is used. Thus, it rules out any front-end specific possibilities. However it is a little surprising why the same does not show when dragonegg is fully used for end-to-end compilation. -Anitha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121107/4bc40780/attachment.html>
On 7 November 2012 15:29, Duncan Sands <baldrick at free.fr> wrote:> > That way the output should be exactly the same as the output dragonegg > would > normally run the LLVM optimizers on, e.g. GCC constant folding and other > such > optimizations which get turned on at -O2 will still have happened > (dragonegg > turns off almost all GCC optimizations by default, but turning everything > off > isn't practical). > > Running the output through "opt -O2" should then do the same optimizations > as > dragonegg would have done. I say "should" because in my experience this > isn't > always true, though it is supposed to be true. >Ok.> > Next comes the codegen stage, which you can emulate using llc (or clang > like > you do below, but llc is more direct). It isn't that easy finding out > exactly > what flags dragonegg passes to llc, so this might be a bit painful. >Yes. This is probably what I need now. Code Generation options used by dragonegg vs clang (or llc as I referred to in last email). Thanks for all the suggestions. - Anitha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121107/e4bb7d76/attachment.html>