Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Borja F. <bor...@gm...> - 2013-07-26 11:18:05
|
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. 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? 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. 2013/7/26 Stepan Dyatkovskiy <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, 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... >> >> >> >> 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...>>> >> >> 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...>>>> >> >> >> 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...>**>__>__>__> >> >> >> 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.>**____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> >> >>> >> >> >> >> >> >> >> >> > > |
