llvm dev - Nov 2012 - [LLVMdev] Help needed on debugging llvm

On 5 November 2012 14:32, Duncan Sands <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>
>> 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.


-- 
* Anitha*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121105/bff76509/attachment.html>

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>
>         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?

Ciao, Duncan.

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>