From: Borja F. <bor...@gm...> - 2013-07-26 11:58:21
|
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...> > 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> >> >> <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>>>> >> >> >> >> >> >> <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<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://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-llvm-devel@lists.**sourceforge.net<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>>>> >> >> >> >> <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> >> >>>> >> >> >> >> >> >> >> >> >> >> >> > |