From: Stepan D. <stp...@na...> - 2013-07-26 11:42:51
|
Borja Ferrer wrote: > Hello Stepan, > No problem with those fixes :) > > 2) It's interesting we get different IR, can you explain more what is > going on here? This is the last bit of inline asm support, the sooner we > fix it the better so we can move on to more interesting things. For next example: int a,b; extern long Calc(void) asm ("CALCULATE"); void f() { Calc(); } avr-clang emits: ; some header ; Function Attrs: noinline nounwind define void @f() #0 { entry: %call = call i32 @"\01CALCULATE"() ; Stepan: note \01 character. ret void } declare i32 @"\01CALCULATE"() #1 ; some footer arm-linux-gnueabi emits: ; some header ; Function Attrs: nounwind define void @f() #0 { entry: %call = call i32 @CALCULATE() ; Stepan: no \01 character. ret void } declare i32 @CALCULATE() #1 ;some footer But .S files looks fine. No \01 characters anywhere. > > About compiling avrlibc: > > >> Also avr-clang emits wrong sequense for .S files. So I'm using > CCAS=avr-gcc. > What do you mean with this? What is wrong? Directory: bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/at90s1200 bash:$ avr-clang -DHAVE_CONFIG_H -I. -I../../../../../avr-libc/avr/lib/avr2/at90s1200 -I../../../.. -I../../../../../avr-libc/common -I../../../../../avr-libc/include -I../../../../include -I../../../../../avr-libc/common -I../../../../../avr-libc/include -I../../../../include -x assembler-with-cpp -mmcu=at90s1200 -DIOSYMFILE=\"iosym/at90s1200.S\" -MT gcrt1.o -MD -MP -MF .deps/gcrt1.Tpo -c -o gcrt1.o ../../../../../avr-libc/crt1/gcrt1.S tons of errors. I suppose thats because clang driver uses different tools for asm files. For the -### command avr-clang shows the next: "avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free" "-main-file-name" "gcrt1.S" "-mrelocation-model" "static" "-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases" "-target-linker-version" "2.22.90.20120924" "-coverage-file" "/tmp/gcrt1-fecbe5.s" "-resource-dir" "/media/stepan/workproj/llvm.project/2-avr/builds/llvm.debug-avr-arm-x86_64.build/Debug+Asserts/bin/../lib/clang/3.4" "-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps" "-MP" "-MT" "gcrt1.o" "-D" "HAVE_CONFIG_H" "-D" "IOSYMFILE=\"iosym/at90s1200.S\"" "-I" "." "-I" "../../../../../avr-libc/avr/lib/avr2/at90s1200" "-I" "../../../.." "-I" "../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include" "-I" "../../../../include" "-I" "../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include" "-I" "../../../../include" "-fno-dwarf-directory-asm" "-fdebug-compilation-dir" "/media/stepan/workproj/llvm.project/2-avr/avr-libc/trunk/build.opt/avr/lib/avr2/at90s1200" "-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign" "-fobjc-runtime=gcc" "-fobjc-default-synthesize-properties" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" "-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp" "../../../../../avr-libc/crt1/gcrt1.S" "/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I" "../../../../../avr-libc/avr/lib/avr2/at90s1200" "-I" "../../../.." "-I" "../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include" "-I" "../../../../include" "-I" "../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include" "-I" "../../../../include" "-mmcu=at90s1200" "-D" "IOSYMFILE=\"iosym/at90s1200.S\"" "-MT" "gcrt1.o" "-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o" "gcrt1.o" "-x" "assembler" "/tmp/gcrt1-fecbe5.s" While avr-gcc uses next sequence: /usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I ../../../../../avr-libc/avr/lib/avr2/at90s1200 -I ../../../.. -I ../../../../../avr-libc/common -I ../../../../../avr-libc/include -I ../../../../include -I ../../../../../avr-libc/common -I ../../../../../avr-libc/include -I ../../../../include -MD gcrt1.d -MF .deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D "IOSYMFILE=\"iosym/at90s1200.S\"" ../../../../../avr-libc/crt1/gcrt1.S "-mmcu=at90s1200" -fno-directives-only -o /tmp/ccK7jMC3.s '-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"' '-MT' 'gcrt1.o' '-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o' 'gcrt1.o' /usr/lib/gcc/avr/4.7.0/../../../avr/bin/as "-mmcu=at90s1200" -mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s > > 2) Since I compile clang as a cross compiler this is not a problem for > me, all llvm binaries are prefixed with avr. > > >> Currently compilation stopped with unsupported movw instruction for > avr2. > Yes, this is going to be a problem. Try to modify the build scripts to > compile everything for mmcu=avr5. We don't support any smaller devices. OK. Will do. -Stepan > > > > 2013/7/26 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>> > > Hello Borja, > > Thanks for fixes! Especially my stupid pieces of code in > AVRAsmPrinter.cpp > > > Back to your post at 01.07.2013: > > You wrote: > [quote] > Yes but the first goal now is to have inline asm feature complete xD > Then we can move into other places of the library. > > Taking a look at the previous emails this is what needs still to be > done: > 1) Implement the missed optimization above for the memory constraint. > Also see if you can come with further cases. Remember to add a test > case. > 2) Implement the stuff in the "C names used in assembler code" section > of the avrlibc manual. You mentioned some issues here in a previous > email. > 3) Implement the a0, a1, etc... constraints. > [/quote] > > 1. Done. > 2. I checked it again. It works, though way of IR generation differs > from ARM back-end for example. > 3. Done. > > Now, I suppose, we have to work more with clang. But it is difficult > since our changes are presented as patches. > > I had tried to compile avr-libc again. I had found clang bug (generic > one: mistreating with builtins): > > http://llvm.org/bugs/show_bug.__cgi?id=16712 > <http://llvm.org/bugs/show_bug.cgi?id=16712> > > Also avr-clang emits wrong sequense for .S files. So I'm using > CCAS=avr-gcc. > > Steps for avr-libc compilation: > > 0. I'm working with avr-libc, svn r2403. > > 1. We also need to apply several changes for it (see the patch in > attachment). > > 2. Currently you should rename "clang" with "avr-clang". "ln -s" doesn't > works. 'avr-gcc' name was hard-coded in configure.ac > <http://configure.ac>, so I did the same > with 'avr-clang'. > > 3. Run configure script as below: > $AVR_LIBC_DIR/configure CC=$LLVM_BIN_DIR/avr-clang --build= --host=avr > CCAS=avr-gcc > > A have also attached my config.log file. > > Currently compilation stopped with unsupported movw instruction for > avr2. > > -Stepan. > > Borja Ferrer wrote: > > Ok, you can commit the patch now. > > > 2013/7/24 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > Borja Ferrer wrote: > > 1) I agree. > > > 3) What happens when you use multibyte constraints with > "e" or "b". > > Just had checked it. It works :-) Though I'll add > test-cases for > them too. > > > 4) Hah ok, btw no need to check for i64? > > In one of our previous mails we decided to restrict i64 > usage, since > avr-gcc doesn't support it properly. > > -Stepan > > > > 2013/7/24 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>>>> > > Hi Borja, > > > > 1) You implemented the "aN" constraint by also > allowing > b,c,d > > constraints. I'm not sure if gcc implements > this, my > guess is > that only > > "a" is needed. Please check to see what gcc > does here. > > For b,c,d avr-gcc acts like it meet %a. I think > its wrong and > untested behaviour, so I just restricted usage to > single > 'a' character. > > > > 2) Make getAlternativeRegName return a char > instead of a > string > since we > > only need to return one letter. > > Done > > > > 3) Related to the changes in > AVRISelLowering.cpp, do we > need to care > > about more register constraints apart of the > ones you > already > covered? > > What you mean? I think all constraints are covered > now. If > no, we > can find out it during compilation (avr-libc, > arduino, etc). > > > > 4) Now that wider types have been covered, > please check > if the > assert I > > commented out in AVRISelLowering.cpp in the > inline asm > code can be > > removed or what. > > I replaced this assertion with error message. > Suppose its > better > than killing the compiler :-) > > New patch is attached. > > -Stepan. > > > Borja Ferrer wrote: > > Hello Stepan, > The patch looks good, but I have some > questions/comments: > > 1) You implemented the "aN" constraint by also > allowing > b,c,d > constraints. I'm not sure if gcc implements > this, my > guess is > that only > "a" is needed. Please check to see what gcc > does here. > 2) Make getAlternativeRegName return a char > instead of > a string > since we > only need to return one letter. > 3) Related to the changes in > AVRISelLowering.cpp, do we > need to care > about more register constraints apart of the > ones you > already > covered? > 4) Now that wider types have been covered, > please check > if the > assert I > commented out in AVRISelLowering.cpp in the > inline asm > code can be > removed or what. > > > > 2013/7/24 Stepan Dyatkovskiy > <stp...@na... <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > <mailto:stp...@na... <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>>>> > > > Hello Borja, > Here is the new patch for multibyte > reference. > Please look > at new > tests to see what was implemented exactly. > To fix issue I described in previous > letter I've > added new reg > classes that contains pairs of 8 bit > registers: > If we pass i32 parameter that should be > split onto > four 8 > bit regs, > we set i16 register class first, then it > would be > replaced > with 8 > bit registers if needed. Currently I see > it is the > only > solution > that doesn't touch vmcore. > > -Stepan. > > Stepan Dyatkovskiy wrote: > > Hello Borja, > Great. I have found out next > inline-asm issue. > When you pass i32 bit type, it could > be split > onto two > registers > only, > no matter which register class you > set for it. > This > behaviour is > implemented in > SelectionDAGBuilder::________visitInlineAsm. > > I think I'll > > implement simplest version of > ExpandInlineAsm > today, > that will fix > operand types properly. > > -Stepan > > Borja Ferrer wrote: > > I've been adding fixes to pass a > ton of > regression > in the > Generic folder. > Currently there are two tests > that fail with a > "cannot select > build_pair" related to adding > 16bit reg > classes in the > inline asm code. > The rest of failing tests are > related with not > being able to > run llc > with -O0. There's a serious > codegen bug > that i spotted > yesterday while > doing the fixes that I need to > work on. > > > 2013/7/22 Borja Ferrer > <bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__>__>__> > > > Hello Stepan, > > 3) Yes, it's the second > case. It's > explained in > http://www.nongnu.org/avr-________libc/user-manual/inline_asm.________html > <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html> > > <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>> > > > <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html> > > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html > <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>> > > > > > > <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html> > > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html > <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>> > > > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html > <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html> > > <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html > <http://www.nongnu.org/avr-libc/user-manual/inline_asm.html>>>> > but in case there are any > doubts > basically it > works > the same way as > multibyte constraints > except that > when you see an > "aN", where N is a > number, you should print > the alternative > regname. Of > course this > should only work for X Y > and Z, not > sure how gcc > complains when you > use another register, or > maybe it > ignores it and > prints the normal > register name. > > > > > > > > ------------------------------________------------------------__--__--__--__------------------ > > > See everything from the browser to the > database with > AppDynamics > Get end-to-end visibility with > application > monitoring from > AppDynamics > Isolate bottlenecks and diagnose root > cause in > seconds. > Start your free trial of AppDynamics > Pro today! > http://pubads.g.doubleclick.________net/gampad/clk?id=__48808831&__iu=____/4140/ostg.__clktrk > > > > <http://pubads.g.doubleclick.______net/gampad/clk?id=48808831&____iu=__/4140/ostg.clktrk > > > <http://pubads.g.doubleclick.____net/gampad/clk?id=48808831&__iu=__/4140/ostg.clktrk > > <http://pubads.g.doubleclick.__net/gampad/clk?id=48808831&iu=__/4140/ostg.clktrk > <http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk>>>> > > _______________________________________________________ > avr-llvm-devel mailing list > > avr-llvm-devel@lists.__sourcef______orge.net > <http://sourcef____orge.net> > <http://sourcef__orge.net> > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists > <mailto:avr-llvm-devel@lists>. > <mailto:avr-llvm-devel@lists > <mailto:avr-llvm-devel@lists>.>______sourceforge.net > <http://sourceforge.net> > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists. > <mailto:avr-llvm-devel@lists.>____sourceforge.net > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>>>> > https://lists.sourceforge.net/________lists/listinfo/avr-llvm-______devel > <https://lists.sourceforge.net/______lists/listinfo/avr-llvm-____devel> > > <https://lists.sourceforge.__net/____lists/listinfo/avr-__llvm-__devel > <https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel>> > > <https://lists.sourceforge.____net/__lists/listinfo/avr-llvm-____devel > > <https://lists.sourceforge.__net/__lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel>>> > > > > <https://lists.sourceforge.______net/lists/listinfo/avr-llvm-______devel > > > <https://lists.sourceforge.____net/lists/listinfo/avr-llvm-____devel > > <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>>>> > > > > > > > > > > |