Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Stepan D. <stp...@na...> - 2013-07-27 14:48:46
|
Hi Borja,
> Currently I'm learning avr-libc configs. How did you restrict to
> compile it for avr5 only?
Ah, never mind. I've managed with that issue. Now I got more serious one.
Next inline asm:
uint16_t __addr16 = (uint16_t)(addr);
uint32_t __result;
__asm__ __volatile__
(
"lpm" "\n\t"
"mov %A0, r0" "\n\t"
"adiw r30, 1" "\n\t"
"lpm" "\n\t"
"mov %B0, r0" "\n\t"
"adiw r30, 1" "\n\t"
"lpm" "\n\t"
"mov %C0, r0" "\n\t"
"adiw r30, 1" "\n\t"
"lpm" "\n\t"
"mov %D0, r0" "\n\t"
: "=r" (__result), "=z" (__addr16)
: "1" (__addr16)
: "r0"
);
Is converted to:
%18 = tail call { i16, i16 } asm sideeffect
"lpm\0A\09
mov ${0:A}, r0\0A\09
adiw r30, 1\0A\09lpm\0A\09
mov ${0:B}, r0\0A\09
adiw r30, 1\0A\09
lpm\0A\09
mov ${0:C}, r0\0A\09
adiw r30, 1\0A\09
lpm\0A\09
mov ${0:D}, r0\0A\09", "=r,=z,1,~{r0}"(i16 %17) #7, !srcloc !3
Note __result (that is 32 bit value) was truncated to i16.
So output IR inline asm instruction become incorrect.
I attached the source with issue. I didn't reduce it yet. Issue seems to
be at string #8633, in pgm_read_dword macro.
Try to compile it with command:
./avr-clang inline-asm-multibyte3X.c -S -o - -Os
Currently it is crashed. I wanna take a rest a bit. Though may be you
have some ideas.
-Stepan.
Borja Ferrer wrote:
> Restrict where? In avrlibc or llvm?
>
> El sábado, 27 de julio de 2013, Stepan Dyatkovskiy escribió:
>
> Currently I'm learning avr-libc configs. How did you restrict to
> compile it for avr5 only?
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Ok I will take a look at that 01 character to see from where
> it's coming
> from.
>
> About the other issue, it's weird, i've managed to build a huge
> c file
> with avr-clang with no errors. Since i have avr-as and the rest
> of avr
> binutils in my PATH, avr-clang calls them automatically to
> assemble and
> link the program. The only thing i MUST do is pass mmcu=avr5
> otherwise i
> get all those movw errors in the assembler. Remember to
> configure LLVM
> with the --target, --host, etc options to build it as a cross
> compiler.
>
> I'm also seeing a lot of references to avr2 and the at90s120 inside
> those cmd lines, I dont know if this makes any difference but
> again, we
> cant compile for those mcus now.
>
>
>
> 2013/7/26 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>>
>
> Borja Ferrer wrote:
>
> Hello Stepan,
>
> No problem with those fixes :)
>
>
> 2) It's interesting we get different IR, can you
> explain more
> what is
> going on here? This is the last bit of inline asm
> support, the
> sooner we
> fix it the better so we can move on to more interesting
> things.
>
>
> For next example:
>
> int a,b;
> extern long Calc(void) asm ("CALCULATE");
> void f() { Calc(); }
>
> avr-clang emits:
>
> ; some header
> ; Function Attrs: noinline nounwind
> define void @f() #0 {
> entry:
> %call = call i32 @"\01CALCULATE"() ; Stepan: note \01
> character.
> ret void
> }
> declare i32 @"\01CALCULATE"() #1
> ; some footer
>
> arm-linux-gnueabi emits:
>
> ; some header
> ; Function Attrs: nounwind
> define void @f() #0 {
> entry:
> %call = call i32 @CALCULATE() ; Stepan: no \01 character.
> ret void
> }
> declare i32 @CALCULATE() #1
> ;some footer
>
> But .S files looks fine. No \01 characters anywhere.
>
>
>
> About compiling avrlibc:
>
> >> Also avr-clang emits wrong sequense for .S files.
> So I'm using
> CCAS=avr-gcc.
> What do you mean with this? What is wrong?
>
> Directory:
> bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/____at90s1200
> bash:$ avr-clang -DHAVE_CONFIG_H -I.
> -I../../../../../avr-libc/avr/____lib/avr2/at90s1200
> -I../../../..
> -I../../../../../avr-libc/____common
> -I../../../../../avr-libc/____include -I../../../../include
> -I../../../../../avr-libc/____common
> -I../../../../../avr-libc/____include -I../../../../include -x
> assembler-with-cpp -mmcu=at90s1200
> -DIOSYMFILE=\"iosym/at90s1200.____S\" -MT gcrt1.o -MD
> -MP -MF
> .deps/gcrt1.Tpo -c -o gcrt1.o
> ../../../../../avr-libc/crt1/____gcrt1.S
>
> tons of errors.
>
> I suppose thats because clang driver uses different tools
> for asm files.
>
> For the -### command avr-clang shows the next:
>
> "avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free"
> "-main-file-name" "gcrt1.S" "-mrelocation-model" "static"
> "-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases"
> "-target-linker-version" "2.22.90.20120924" "-coverage-file"
> "/tmp/gcrt1-fecbe5.s" "-resource-dir"
>
> "/media/stepan/workproj/llvm.____project/2-avr/builds/llvm.____debug-avr-arm-x86_64.build/____Debug+Asserts/bin/../lib/____clang/3.4"
> "-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps"
> "-MP" "-MT"
> "gcrt1.o" "-D" "HAVE_CONFIG_H" "-D"
> "IOSYMFILE=\"iosym/at90s1200.____S\"" "-I" "." "-I"
> "../../../../../avr-libc/avr/____lib/avr2/at90s1200" "-I"
> "../../../.." "-I" "../../../../../avr-libc/____common" "-I"
> "../../../../../avr-libc/____include" "-I"
> "../../../../include" "-I"
> "../../../../../avr-libc/____common" "-I"
> "../../../../../avr-libc/____include" "-I"
> "../../../../include"
> "-fno-dwarf-directory-asm" "-fdebug-compilation-dir"
>
> "/media/stepan/workproj/llvm.____project/2-avr/avr-libc/trunk/____build.opt/avr/lib/avr2/____at90s1200"
> "-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign"
> "-fobjc-runtime=gcc" "-fobjc-default-synthesize-____properties"
> "-fdiagnostics-show-option" "-fcolor-diagnostics"
> "-vectorize-loops"
> "-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp"
> "../../../../../avr-libc/crt1/____gcrt1.S"
>
> "/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I"
> "../../../../../avr-libc/avr/____lib/avr2/at90s1200" "-I"
> "../../../.." "-I" "../../../../../avr-libc/____common" "-I"
> "../../../../../avr-libc/____include" "-I"
> "../../../../include" "-I"
> "../../../../../avr-libc/____common" "-I"
> "../../../../../avr-libc/____include" "-I"
> "../../../../include"
> "-mmcu=at90s1200" "-D"
> "IOSYMFILE=\"iosym/at90s1200.____S\"" "-MT"
> "gcrt1.o" "-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o"
> "gcrt1.o"
> "-x" "assembler" "/tmp/gcrt1-fecbe5.s"
>
> While avr-gcc uses next sequence:
>
> /usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I
> ../../../../../avr-libc/avr/____lib/avr2/at90s1200 -I
> ../../../.. -I
> ../../../../../avr-libc/common -I
> ../../../../../avr-libc/____include
> -I ../../../../include -I ../../../../../avr-libc/common -I
> ../../../../../avr-libc/____include -I ../../../../include
> -MD gcrt1.d
> -MF .deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D
> "IOSYMFILE=\"iosym/at90s1200.____S\""
> ../../../../../avr-libc/crt1/____gcrt1.S "-mmcu=at90s1200"
> -fno-directives-only -o /tmp/ccK7jMC3.s
> '-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"____'
> '-MT'
> 'gcrt1.o' '-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o'
> 'gcrt1.o'
>
> /usr/lib/gcc/avr/4.7.0/../../.____./avr/bin/as
> "-mmcu=at90s1200"
> -mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s
>
>
>
>
> 2) Since I compile clang as a cross compiler this is not a
> problem for
> me, all llvm binaries are prefixed with avr.
>
> >> Currently compilation stopped with unsupported movw
> instruction for
> avr2.
> Yes, this is going to be a problem. Try to modify the build
> scripts to
> compile everything for mmcu=avr5. We don't support any
> smaller
> devices.
>
>
> OK. Will do.
>
> -Stepan
>
>
>
>
> 2013/7/26 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
>
> Hello Borja,
>
> Thanks for fixes! Especially my stupid pieces of
> code in
> AVRAsmPrinter.cpp
>
>
> Back to your post at 01.07.2013:
>
> You wrote:
> [quote]
> Yes but the first goal now is to have inline asm
> feature
> complete xD
> Then we can move into other places of the library.
>
> Taking a look at the previous emails this is what
> needs
> still to be
> done:
> 1) Implement the missed optimization above for the
> memory
> constraint.
> Also see if you can come with further cases.
> Remember to
> add a test
> case.
> 2) Implement the stuff in the "C names used in
> assembler
> code" section
> of the avrlibc manual. You mentioned some issues
> here in a
> previous
> email.
> 3) Implement the a0, a1, etc... constraints.
> [/quote]
>
> 1. Done.
> 2. I checked it again. It works, though way of IR
> generation differs
> from ARM back-end for example.
> 3. Done.
>
> Now, I suppose, we have to work more with clang.
> But it is
> difficult
> since our changes are presented as patches.
>
> I had tried to compile avr-libc again. I had found
> clang
> bug (generic
> one: mistreating with builtins):
>
> http://llvm.org/bugs/show_bug.______cgi?id=16712
> <http://llvm.org/bugs/show_bug.____cgi?id=16712>
> <http://llvm.org/bugs/show___bug.__cgi?id=16712
> <http://llvm.org/bugs/show_bug.__cgi?id=16712>>
>
> <http://llvm.org/bugs/show_____bug.cgi?id=16712
> <http://llvm.org/bugs/show___bug.cgi?id=16712>
> <http://llvm.org/bugs/show___bug.cgi?id=16712
> <http://llvm.org/bugs/show_bug.cgi?id=16712>>>
>
> Also avr-clang emits wrong sequense for .S files.
> So I'm using
> CCAS=avr-gcc.
>
> Steps for avr-libc compilation:
>
> 0. I'm working with avr-libc, svn r2403.
>
> 1. We also need to apply several changes for it
> (see the
> patch in
> attachment).
>
> 2. Currently you should rename "clang" with
> "avr-clang".
> "ln -s" doesn't
> works. 'avr-gcc' name was hard-coded in
> configure.ac <http://configure.ac>
> <http://configure.ac>
> <http://configure.ac>, so I did the same
>
> with 'avr-clang'.
>
> 3. Run configure script as below:
> $AVR_LIBC_DIR/configure CC=$LLVM_BIN_DIR/avr-clang
> --build=
> --host=avr
> CCAS=avr-gcc
>
> A have also attached my config.log file.
>
> Currently compilation stopped with unsupported movw
> instruction for
> avr2.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Ok, you can commit the patch now.
>
>
> 2013/7/24 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>
> <mailto:stp...@na... <mailto:stp...@na...>
>
> <mailto:stp...@na...
> <mailto:stp...@na...>>>>
>
> Borja Ferrer wrote:
>
> 1) I agree.
>
>
> 3) What happens when you use multibyte
> constraints with
> "e" or "b".
>
> Just had checked it. It works :-) Though
> I'll add
> test-cases for
> them too.
>
>
> 4) Hah ok, btw no need to check for i64?
>
> In one of our previous mails we decided to
> restrict i64
> usage, since
> avr-gcc doesn't support it properly.
>
> -Stepan
>
>
>
> 2013/7/24 Stepan Dyatkovskiy
> <stp...@na... <mailto:stp...@na...>
> <mailto:stp...@na...
> <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
> <mailto:stp...@na...
> <mailto:stp...@na...>
> <mailto:stp...@na... <mailto:stp...@na...>>
> <mailto:stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>
>
> Hi Borja,
>
>
> > 1) You implemented the "aN"
> constraint
> by also
> allowing
> b,c,d
> > constraints. I'm not sure if gcc
> implements
> this, my
> guess is
> that only
> > "a" is needed. Please check
> to see
> what gcc
> does here.
>
> For b,c,d avr-gcc acts like it
> meet %a. I
> think
> its wrong and
> untested behaviour, so I just
> restricted
> usage to
> single
> 'a' character.
>
>
> > 2) Make getAlternativeRegName
> return a
> char
> instead of a
> string
> since we
> > only need to return one letter.
>
> Done
>
>
> > 3) Related to the changes in
> AVRISelLowering.cpp, do we
> need to care
> > about more register
> constraints apart
> of the
> ones you
> already
> covered?
>
> What you mean? I think all
> constraints
> are covered
> now. If
> no, we
> can find out it during
> compilation (avr-libc,
> arduino, etc).
>
>
> > 4) Now that wider types have
> been covered,
> please check
> if the
> assert I
> > commented out in
> AVRISelLowering.cpp
> in the
> inline asm
> code can be
> > removed or what.
>
> I replaced this assertion with
> error message.
> Suppose its
> better
> than killing the compiler :-)
>
> New patch is attached.
>
> -Stepan.
>
>
> Borja Ferrer wrote:
>
> Hello Stepan,
> The patch looks good, but I
> have some
> questions/comments:
>
> 1) You implemented the "aN"
> constraint by also
> allowing
> b,c,d
> constraints. I'm not sure if gcc
> implements
> this, my
> guess is
> that only
> "a" is needed. Please check
> to see
> what gcc
> does here.
> 2) Make
> getAlternativeRegName return
> a char
> instead of
> a string
> since we
> only need to return one letter.
> 3) Related to the changes in
> AVRISelLowering.cpp, do we
> need to care
> about more register
> constraints apart
> of the
> ones you
> already
> covered?
> 4) Now that wider types have
> been
> covered,
> please check
> if the
> assert I
> commented out in
> AVRISelLowering.cpp
> in the
> inline asm
> code can be
> removed or what.
>
>
>
> 2013/7/24 Stepan Dyatkovskiy
> <stp...@na... <mailto:stpworld@narod.r
> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>>
>
>
> Hello Borja,
> Here is the new patch
> for multibyte
> reference.
> Please look
> at new
> tests to see what was
> implemented exactly.
> To fix issue I
> described in previous
> letter I've
> added new reg
> classes that contains
> pairs of 8 bit
> registers:
> If we pass i32
> parameter that
> should be
> split onto
> four 8
> bit regs,
> we set i16 register
> class first,
> then it
> would be
> replaced
> with 8
> bit registers if needed.
> Currently I see
> it is the
> only
>
|
