From: Stepan D. <stp...@na...> - 2013-07-27 14:48:46
|
Hi Borja, > Currently I'm learning avr-libc configs. How did you restrict to > compile it for avr5 only? Ah, never mind. I've managed with that issue. Now I got more serious one. Next inline asm: uint16_t __addr16 = (uint16_t)(addr); uint32_t __result; __asm__ __volatile__ ( "lpm" "\n\t" "mov %A0, r0" "\n\t" "adiw r30, 1" "\n\t" "lpm" "\n\t" "mov %B0, r0" "\n\t" "adiw r30, 1" "\n\t" "lpm" "\n\t" "mov %C0, r0" "\n\t" "adiw r30, 1" "\n\t" "lpm" "\n\t" "mov %D0, r0" "\n\t" : "=r" (__result), "=z" (__addr16) : "1" (__addr16) : "r0" ); Is converted to: %18 = tail call { i16, i16 } asm sideeffect "lpm\0A\09 mov ${0:A}, r0\0A\09 adiw r30, 1\0A\09lpm\0A\09 mov ${0:B}, r0\0A\09 adiw r30, 1\0A\09 lpm\0A\09 mov ${0:C}, r0\0A\09 adiw r30, 1\0A\09 lpm\0A\09 mov ${0:D}, r0\0A\09", "=r,=z,1,~{r0}"(i16 %17) #7, !srcloc !3 Note __result (that is 32 bit value) was truncated to i16. So output IR inline asm instruction become incorrect. I attached the source with issue. I didn't reduce it yet. Issue seems to be at string #8633, in pgm_read_dword macro. Try to compile it with command: ./avr-clang inline-asm-multibyte3X.c -S -o - -Os Currently it is crashed. I wanna take a rest a bit. Though may be you have some ideas. -Stepan. Borja Ferrer wrote: > Restrict where? In avrlibc or llvm? > > El sábado, 27 de julio de 2013, Stepan Dyatkovskiy escribió: > > Currently I'm learning avr-libc configs. How did you restrict to > compile it for avr5 only? > > -Stepan. > > Borja Ferrer wrote: > > Ok I will take a look at that 01 character to see from where > it's coming > from. > > About the other issue, it's weird, i've managed to build a huge > c file > with avr-clang with no errors. Since i have avr-as and the rest > of avr > binutils in my PATH, avr-clang calls them automatically to > assemble and > link the program. The only thing i MUST do is pass mmcu=avr5 > otherwise i > get all those movw errors in the assembler. Remember to > configure LLVM > with the --target, --host, etc options to build it as a cross > compiler. > > I'm also seeing a lot of references to avr2 and the at90s120 inside > those cmd lines, I dont know if this makes any difference but > again, we > cant compile for those mcus now. > > > > 2013/7/26 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...>> > > 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...> <mailto: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> > <http://llvm.org/bugs/show___bug.__cgi?id=16712 > <http://llvm.org/bugs/show_bug.__cgi?id=16712>> > > <http://llvm.org/bugs/show_____bug.cgi?id=16712 > <http://llvm.org/bugs/show___bug.cgi?id=16712> > <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> > <http://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...>> > <mailto: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...>>> > <mailto: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:stpworld@narod.r > <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 > |