Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
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>
>> >>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
