thr3ads.net - llvm dev - [LLVMdev] Dragonegg + IR + llc = Dragonegg directly [Apr 2012]

If this information is useful, please help other people find it:
Share via:

Martin Apel

2012-Apr-17 14:47 UTC

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

Hi Duncan,

thanks for the quick reply. I understand, that the generated code is
different between the two approaches.
But I would still expect IEEE rules to be respected in any case. I do
not see any reason why -fPIC -fomit-frame-pointer
and the like should have any impact on the results computed by the
generated code.

Are there any options I can set on the command line of llc to force the
identical behaviour with respect to numerical stability?
I tried the some of the llc options lik**e --disable-excess-fp-precision
and --disable-fp-elim, but without success.

Martin

On 17/04/12 15:12, Duncan Sands wrote:> Hi Martin,
>
>> I tried using dragonegg to compile some numerical software of ours. I
>> tried out two different approaches expecting both would yield the same
>> results:
>> 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f   (I ommitted a
>> bunch of additional arguments for brevity)
>> 2. gfortran-4.6 -fplugin=dragonegg-3.0 -fplugin-arg-dragonegg-emit-ir
-S
>> -o test.ll test.f
>>     llc -O0 -o test.s test.ll
>>     as -o test.o test.s
>>
>> When comparing the results of our software compiled with gfortran-4.6
>> without LLVM with approach 1, I get the same results for both versions.
>> However, when I use approach 2, the computation results differ from the
>> original version.
>>
>> I expected that using the dragonegg plugin to generate native code
>> directly would internally do more or less the same as the explicit step
of
>> approach 2, but this does not seem to be the case. Any ideas why this
>> happens?
> different arguments are being passed to the code generators.  In the
> CreateTargetMachine function in Backend.cpp options like -fPIC,
> -fomit-frame-pointer and so on are transformed into LLVM languages
> and passed to the code generators.  Same goes for feature strings
> (whether you are targeting a machine supporting SSE and so on).  A
> few more generic codegen options are set in ConfigureLLVM.
>
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 

Martin Apel                                    
Software Architect                              
Phone:   + 49 8105 77266-53
E-Mail:  martin.apel at simpack.de

SIMPACK AG
Friedrichshafener Strasse 1, 82205 Gilching, Germany
info at simpack.de, www.simpack.com
Phone: + 49 8105 77266-0
Fax:   + 49 8105 77266-11


Executive Board: Dr. Alexander Eichberger, Dr. Lutz Mauer
Chair of Supervisory Board: Silvia Förster (CPA)
Commercial Register München HRB 181 229

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120417/6e6df583/attachment.html>

Anton Korobeynikov

2012-Apr-17 15:14 UTC

head link

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

Martin,
> Are there any options I can set on the command line of llc to force the
> identical behaviour with respect to numerical stability?
> I tried the some of the llc options like --disable-excess-fp-precision and
> --disable-fp-elim, but without success.And the first cmdline contained -O0 as well? Or... it was something
different? What if you omit -O0 from llc for the second time?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Duncan Sands

2012-Apr-17 15:18 UTC

head link

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

Hi Martin,
> thanks for the quick reply. I understand, that the generated code is
different
> between the two approaches.
> But I would still expect IEEE rules to be respected in any case. I do not
see
> any reason why -fPIC -fomit-frame-pointer
> and the like should have any impact on the results computed by the
generated code.
probably in the direct case you are using the x86 floating point stack and in
the llc case you are using xmm registers.  This is because dragonegg picks up
what gcc thinks the target is, and gcc is very conservative, while llc defaults
to targeting the host machine.
> Are there any options I can set on the command line of llc to force the
> identical behaviour with respect to numerical stability?
Try llc -mcpu=i386

You may also need to turn off some cpu attributes like SSE, I don't recall,
see
   llc -mcpu=help test.ll
for a list.

Ciao, Duncan.
> I tried the some of the llc options lik**e --disable-excess-fp-precision
and
> --disable-fp-elim, but without success.
>
> Martin
>
> On 17/04/12 15:12, Duncan Sands wrote:
>> Hi Martin,
>>
>>> I tried using dragonegg to compile some numerical software of ours.
I
>>> tried out two different approaches expecting both would yield the
same
>>> results:
>>> 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f   (I
ommitted a
>>> bunch of additional arguments for brevity)
>>> 2. gfortran-4.6 -fplugin=dragonegg-3.0
-fplugin-arg-dragonegg-emit-ir -S
>>> -o test.ll test.f
>>>      llc -O0 -o test.s test.ll
>>>      as -o test.o test.s
>>>
>>> When comparing the results of our software compiled with
gfortran-4.6
>>> without LLVM with approach 1, I get the same results for both
versions.
>>> However, when I use approach 2, the computation results differ from
the
>>> original version.
>>>
>>> I expected that using the dragonegg plugin to generate native code
>>> directly would internally do more or less the same as the explicit
step of
>>> approach 2, but this does not seem to be the case. Any ideas why
this
>>> happens?
>> different arguments are being passed to the code generators.  In the
>> CreateTargetMachine function in Backend.cpp options like -fPIC,
>> -fomit-frame-pointer and so on are transformed into LLVM languages
>> and passed to the code generators.  Same goes for feature strings
>> (whether you are targeting a machine supporting SSE and so on).  A
>> few more generic codegen options are set in ConfigureLLVM.
>>
>> Ciao, Duncan.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu  <mailto:LLVMdev at cs.uiuc.edu>         
http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> --
>
> Martin Apel
> Software Architect
> Phone:   + 49 8105 77266-53
> E-Mail:martin.apel at simpack.de  <mailto:martin.apel at simpack.de>
>
> SIMPACK AG
> Friedrichshafener Strasse 1, 82205 Gilching, Germany
> info at simpack.de  <mailto:info at simpack.de>,www.simpack.com 
<http://www.simpack.com>
> Phone: + 49 8105 77266-0
> Fax:   + 49 8105 77266-11
>
>
> Executive Board: Dr. Alexander Eichberger, Dr. Lutz Mauer
> Chair of Supervisory Board: Silvia Förster (CPA)
> Commercial Register München HRB 181 229
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Martin Apel

2012-Apr-17 15:26 UTC

head link

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

Hi Anton,

yes the first command line contained -O0 as well. I also tried omitting
-O0 from the llc command line, but this made no difference.

Martin

On 17/04/12 17:14, Anton Korobeynikov wrote:> Martin,
>
>> Are there any options I can set on the command line of llc to force the
>> identical behaviour with respect to numerical stability?
>> I tried the some of the llc options like --disable-excess-fp-precision
and
>> --disable-fp-elim, but without success.
> And the first cmdline contained -O0 as well? Or... it was something
> different? What if you omit -O0 from llc for the second time?
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University

Anton Korobeynikov

2012-Apr-17 16:03 UTC

head link

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

> You may also need to turn off some cpu attributes like SSE, I don't
recall, see
>   llc -mcpu=help test.llMaybe it'd be easier at dragonegg level -mfpmath=sse / x87 - and
compare the results

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Martin Apel

2012-Apr-18 07:55 UTC

head link

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

Hi Duncan,

I tried it with llc -mcpu=i386 and now the results are the same. Thanks
for the tip.
I am in the process of writing an optimization pass involving constant
propagation,
and I want to be sure, that this pass does not modify the numerical results.

Martin

On 17/04/12 17:18, Duncan Sands wrote:> Hi Martin,
>
>> thanks for the quick reply. I understand, that the generated code is
different
>> between the two approaches.
>> But I would still expect IEEE rules to be respected in any case. I do
not see
>> any reason why -fPIC -fomit-frame-pointer
>> and the like should have any impact on the results computed by the
generated code.
> probably in the direct case you are using the x86 floating point stack and
in
> the llc case you are using xmm registers.  This is because dragonegg picks
up
> what gcc thinks the target is, and gcc is very conservative, while llc
defaults
> to targeting the host machine.
>
>> Are there any options I can set on the command line of llc to force the
>> identical behaviour with respect to numerical stability?
> Try llc -mcpu=i386
>
> You may also need to turn off some cpu attributes like SSE, I don't
recall, see
>    llc -mcpu=help test.ll
> for a list.
>
> Ciao, Duncan.
>
>> I tried the some of the llc options lik**e
--disable-excess-fp-precision and
>> --disable-fp-elim, but without success.
>>
>> Martin
>>
>> On 17/04/12 15:12, Duncan Sands wrote:
>>> Hi Martin,
>>>
>>>> I tried using dragonegg to compile some numerical software of
ours. I
>>>> tried out two different approaches expecting both would yield
the same
>>>> results:
>>>> 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f   (I
ommitted a
>>>> bunch of additional arguments for brevity)
>>>> 2. gfortran-4.6 -fplugin=dragonegg-3.0
-fplugin-arg-dragonegg-emit-ir -S
>>>> -o test.ll test.f
>>>>      llc -O0 -o test.s test.ll
>>>>      as -o test.o test.s
>>>>
>>>> When comparing the results of our software compiled with
gfortran-4.6
>>>> without LLVM with approach 1, I get the same results for both
versions.
>>>> However, when I use approach 2, the computation results differ
from the
>>>> original version.
>>>>
>>>> I expected that using the dragonegg plugin to generate native
code
>>>> directly would internally do more or less the same as the
explicit step of
>>>> approach 2, but this does not seem to be the case. Any ideas
why this
>>>> happens?
>>> different arguments are being passed to the code generators.  In
the
>>> CreateTargetMachine function in Backend.cpp options like -fPIC,
>>> -fomit-frame-pointer and so on are transformed into LLVM languages
>>> and passed to the code generators.  Same goes for feature strings
>>> (whether you are targeting a machine supporting SSE and so on).  A
>>> few more generic codegen options are set in ConfigureLLVM.
>>>
>>> Ciao, Duncan.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu  <mailto:LLVMdev at cs.uiuc.edu>      
http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> --
>>
>> Martin Apel
>> Software Architect
>> Phone:   + 49 8105 77266-53
>> E-Mail:martin.apel at simpack.de  <mailto:martin.apel at
simpack.de>
>>
>> SIMPACK AG
>> Friedrichshafener Strasse 1, 82205 Gilching, Germany
>> info at simpack.de  <mailto:info at simpack.de>,www.simpack.com 
<http://www.simpack.com>
>> Phone: + 49 8105 77266-0
>> Fax:   + 49 8105 77266-11
>>
>>
>> Executive Board: Dr. Alexander Eichberger, Dr. Lutz Mauer
>> Chair of Supervisory Board: Silvia Förster (CPA)
>> Commercial Register München HRB 181 229
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 

Martin Apel                                    
Software Architect                              
Phone:   + 49 8105 77266-53
E-Mail:  martin.apel at simpack.de

SIMPACK AG
Friedrichshafener Strasse 1, 82205 Gilching, Germany
info at simpack.de, www.simpack.com
Phone: + 49 8105 77266-0
Fax:   + 49 8105 77266-11


Executive Board: Dr. Alexander Eichberger, Dr. Lutz Mauer
Chair of Supervisory Board: Silvia Förster (CPA)
Commercial Register München HRB 181 229

Reasonably Related Threads

Search for more seemingly similar threads

llvm dev - Apr 2012 - [LLVMdev] Dragonegg + IR + llc = Dragonegg directly

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

Reasonably Related Threads