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
[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
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
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
[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
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
- [LLVMdev] Dragonegg + IR + llc = Dragonegg directly
- [LLVMdev] Dragonegg + IR + llc = Dragonegg directly
- [LLVMdev] Dragonegg + IR + llc = Dragonegg directly
- [LLVMdev] How to unroll loops in opposite loop nest order
- [LLVMdev] Missing optimization in constant propagation?