[LLVMdev] Help needed on debugging llvm

[Duncan Sands]

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.