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