<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Duncan,<br>
<br>
thanks for the quick reply. I understand, that the generated code is
different between the two approaches.<br>
But I would still expect IEEE rules to be respected in any case. I
do not see any reason why -fPIC -fomit-frame-pointer<br>
and the like should have any impact on the results computed by the
generated code.<br>
<br>
Are there any options I can set on the command line of llc to force
the identical behaviour with respect to numerical stability?<br>
I tried the some of the llc options lik<strong></strong>e
--disable-excess-fp-precision and --disable-fp-elim, but without
success.<br>
<br>
Martin<br>
<br>
On 17/04/12 15:12, Duncan Sands wrote:
<blockquote cite="mid:4F8D6C2A.7030501@free.fr" type="cite">
<pre wrap="">Hi Martin,
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
<tt><br>
</tt>
<div class="moz-signature">-- <br>
<pre>Martin Apel
Software Architect
Phone: + 49 8105 77266-53
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:martin.apel@simpack.de">martin.apel@simpack.de</a>
SIMPACK AG
Friedrichshafener Strasse 1, 82205 Gilching, Germany
<a class="moz-txt-link-abbreviated" href="mailto:info@simpack.de">info@simpack.de</a>, <a class="moz-txt-link-abbreviated" href="http://www.simpack.com">www.simpack.com</a>
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
</pre>
</div>
</body>
</html>