Menu
▾
▴
avr-llvm-devel
|
From: Stepan D. <stp...@na...> - 2013-09-16 18:27:35
|
Hello Borja. I hope so. But the way they suggested is a bit problematic :-( I'm pushing it... -Stepan Borja Ferrer wrote: > Stepan did your patch ever get commited to the clang repo? > > El viernes, 9 de agosto de 2013, Borja Ferrer escribió: > > Hello Stepan, > > Don't worry about it now, enjoy your vacation :) > > > > 2013/8/9 Stepan Dyatkovskiy <stp...@na...> > > Sorry guys, I'm on vocation till 22nd of August. Currently I'm > in mountains and not able to compile anything. Though, if you > want to commit it ASAP, I can consult you by email. > > Sincerely, > Stepan Dyatkovskiy > 06.08.2013, 14:55, "Borja Ferrer" <bor...@gm...>: >> Ok then, Stepan commit your patch for avrlibc when you can. >> Ping Eric? >> >> El miércoles, 31 de julio de 2013, John Myers escribió: >> >> >> 3) Commit this patch to SVN, and create a new >> directory for it, John any suggestions about the dir >> structure for this? >> >> I would just make a /branches/patches directory and place >> the avr-libc patch there. >> >> , >> >> ------------------------------------------------------------------------------ >> Get your SQL database under version control now! >> Version control is standard for application code, but >> databases havent >> caught up. So what steps can you take to put your SQL >> databases under >> version control? Why should you start doing it? Read more to >> find out. >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> >> , >> >> _______________________________________________ >> avr-llvm-devel mailing list >> avr...@li... >> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >> > |
|
From: Borja F. <bor...@gm...> - 2013-09-16 18:58:59
|
Last time I checked it they didnt reply to your message in the commit list. So try pinging them. El lunes, 16 de septiembre de 2013, Stepan Dyatkovskiy escribió: > Hello Borja. I hope so. But the way they suggested is a bit problematic > :-( I'm pushing it... > -Stepan > Borja Ferrer wrote: > >> Stepan did your patch ever get commited to the clang repo? >> >> El viernes, 9 de agosto de 2013, Borja Ferrer escribió: >> >> Hello Stepan, >> >> Don't worry about it now, enjoy your vacation :) >> >> >> >> 2013/8/9 Stepan Dyatkovskiy <stp...@na...> >> >> Sorry guys, I'm on vocation till 22nd of August. Currently I'm >> in mountains and not able to compile anything. Though, if you >> want to commit it ASAP, I can consult you by email. >> >> Sincerely, >> Stepan Dyatkovskiy >> 06.08.2013, 14:55, "Borja Ferrer" <bor...@gm...>: >> >>> Ok then, Stepan commit your patch for avrlibc when you can. >>> Ping Eric? >>> >>> El miércoles, 31 de julio de 2013, John Myers escribió: >>> >>> >>> 3) Commit this patch to SVN, and create a new >>> directory for it, John any suggestions about the dir >>> structure for this? >>> >>> I would just make a /branches/patches directory and place >>> the avr-libc patch there. >>> >>> , >>> >>> ------------------------------**------------------------------** >>> ------------------ >>> Get your SQL database under version control now! >>> Version control is standard for application code, but >>> databases havent >>> caught up. So what steps can you take to put your SQL >>> databases under >>> version control? Why should you start doing it? Read more to >>> find out. >>> http://pubads.g.doubleclick.**net/gampad/clk?id=48897031&iu=** >>> /4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk> >>> >>> , >>> >>> ______________________________**_________________ >>> avr-llvm-devel mailing list >>> avr...@li... >>> https://lists.sourceforge.net/**lists/listinfo/avr-llvm-devel<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> >>> >>> >> > |
|
From: Borja F. <bor...@gm...> - 2013-09-17 22:57:06
|
Ok now I've seen all your messages in the list. Thanks for getting this done. You only need to recommit that patch that made the PPC bots fail. El lunes, 16 de septiembre de 2013, Borja Ferrer escribió: > Last time I checked it they didnt reply to your message in the commit > list. So try pinging them. > > El lunes, 16 de septiembre de 2013, Stepan Dyatkovskiy escribió: > >> Hello Borja. I hope so. But the way they suggested is a bit problematic >> :-( I'm pushing it... >> -Stepan >> Borja Ferrer wrote: >> >>> Stepan did your patch ever get commited to the clang repo? >>> >>> El viernes, 9 de agosto de 2013, Borja Ferrer escribió: >>> >>> Hello Stepan, >>> >>> Don't worry about it now, enjoy your vacation :) >>> >>> >>> >>> 2013/8/9 Stepan Dyatkovskiy <stp...@na...> >>> >>> Sorry guys, I'm on vocation till 22nd of August. Currently I'm >>> in mountains and not able to compile anything. Though, if you >>> want to commit it ASAP, I can consult you by email. >>> >>> Sincerely, >>> Stepan Dyatkovskiy >>> 06.08.2013, 14:55, "Borja Ferrer" <bor...@gm...>: >>> >>>> Ok then, Stepan commit your patch for avrlibc when you can. >>>> Ping Eric? >>>> >>>> El miércoles, 31 de julio de 2013, John Myers escribió: >>>> >>>> >>>> 3) Commit this patch to SVN, and create a new >>>> directory for it, John any suggestions about the dir >>>> structure for this? >>>> >>>> I would just make a /branches/patches directory and place >>>> the avr-libc patch there. >>>> >>>> , >>>> >>>> ------------------------------**------------------------------* >>>> *------------------ >>>> Get your SQL database under version control now! >>>> Version control is standard for application code, but >>>> databases havent >>>> caught up. So what steps can you take to put your SQL >>>> databases under >>>> version control? Why should you start doing it? Read more to >>>> find out. >>>> http://pubads.g.doubleclick.**net/gampad/clk?id=48897031&iu=** >>>> /4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk> >>>> >>>> , >>>> >>>> ______________________________**_________________ >>>> avr-llvm-devel mailing list >>>> avr...@li... >>>> https://lists.sourceforge.net/**lists/listinfo/avr-llvm-devel<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> >>>> >>>> >>> >> |
|
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> >> >>> >> >> >> >> >> >> >> >> > > |
|
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>>>>
>
>
>
>
>
>
>
>
>
>
|
|
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>
>> >>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-27 11:12:49
|
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>>
>
> 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>, 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: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...
> <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...>>__>__>__>
>
> <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...
> <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>>.
> <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>
>
> <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>>>>
>
>
>
>
> <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>>>>>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-27 14:10:57
|
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>, 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
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-27 14:48:46
Attachments:
inline-asm-multibyte-issue.tgz
|
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
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 16:46:29
|
Hello Stepan,
1) It seems clang mangles assembly functions names by prefixing a \01
character. I haven't found yet the code that does this depending on the
target used.
2) About the code above, I'm assuming you got that inline asm code from the
__LPM_dword_classic__ macro. This is what I'm getting for the following C
code:
typedef unsigned int uint16_t;
typedef unsigned long uint32_t;
#define __LPM_dword_classic__(addr) \
(__extension__({ \
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" \
); \
__result; \
}))
unsigned long inlineasm(unsigned int addr)
{
return __LPM_dword_classic__(addr);
}
clang produces:
define i32 @inlineasm(i16 %addr) #0 {
entry:
%0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov ${0:A},
r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, r0\0A\09adiw r30,
1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:D},
r0\0A\09", "=r,=z,1,~{r0}"(i16 %addr) #2, !srcloc !4
%asmresult = extractvalue { i32, i16 } %0, 0
ret i32 %asmresult
}
No truncations here as far i can tell. Try this code and see what you get.
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 16:57:33
|
I've compiled the file you attached, ignoring all warnings i get from clang
about the unknown attributes like progmem, i'm getting the assertion
"multibyte index is out of range."
2013/7/28 Borja Ferrer <bor...@gm...>
> Hello Stepan,
>
> 1) It seems clang mangles assembly functions names by prefixing a \01
> character. I haven't found yet the code that does this depending on the
> target used.
>
> 2) About the code above, I'm assuming you got that inline asm code from
> the __LPM_dword_classic__ macro. This is what I'm getting for the following
> C code:
> typedef unsigned int uint16_t;
> typedef unsigned long uint32_t;
>
> #define __LPM_dword_classic__(addr) \
> (__extension__({ \
>
> 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" \
> ); \
> __result; \
> }))
> unsigned long inlineasm(unsigned int addr)
> {
> return __LPM_dword_classic__(addr);
> }
>
> clang produces:
>
> define i32 @inlineasm(i16 %addr) #0 {
> entry:
> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov ${0:A},
> r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, r0\0A\09adiw r30,
> 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:D},
> r0\0A\09", "=r,=z,1,~{r0}"(i16 %addr) #2, !srcloc !4
> %asmresult = extractvalue { i32, i16 } %0, 0
> ret i32 %asmresult
> }
>
> No truncations here as far i can tell. Try this code and see what you get.
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 18:37:18
|
Ok this was a bit insane to reduce but I've found the offending lines.
The problem is how uint32_t and uint16_t are defined:
typedef unsigned int uint16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__)));
I have no idea what this syntax is, but if you refedefine those types to
unsigned int / long the problem goes away.
Now im getting an error in llc: error: couldn't allocate input reg for
constraint 'r'
2013/7/28 Borja Ferrer <bor...@gm...>
> I've compiled the file you attached, ignoring all warnings i get from
> clang about the unknown attributes like progmem, i'm getting the assertion
> "multibyte index is out of range."
>
>
> 2013/7/28 Borja Ferrer <bor...@gm...>
>
>> Hello Stepan,
>>
>> 1) It seems clang mangles assembly functions names by prefixing a \01
>> character. I haven't found yet the code that does this depending on the
>> target used.
>>
>> 2) About the code above, I'm assuming you got that inline asm code from
>> the __LPM_dword_classic__ macro. This is what I'm getting for the following
>> C code:
>> typedef unsigned int uint16_t;
>> typedef unsigned long uint32_t;
>>
>> #define __LPM_dword_classic__(addr) \
>> (__extension__({ \
>>
>> 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" \
>> ); \
>> __result; \
>> }))
>> unsigned long inlineasm(unsigned int addr)
>> {
>> return __LPM_dword_classic__(addr);
>> }
>>
>> clang produces:
>>
>> define i32 @inlineasm(i16 %addr) #0 {
>> entry:
>> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov ${0:A},
>> r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, r0\0A\09adiw r30,
>> 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:D},
>> r0\0A\09", "=r,=z,1,~{r0}"(i16 %addr) #2, !srcloc !4
>> %asmresult = extractvalue { i32, i16 } %0, 0
>> ret i32 %asmresult
>> }
>>
>> No truncations here as far i can tell. Try this code and see what you get.
>>
>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X