[LLVMdev] Dragonegg + IR + llc = Dragonegg directly

Duncan Sands baldrick at free.fr
Tue Apr 17 08:18:04 PDT 2012


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




More information about the llvm-dev mailing list