Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Stepan D. <stp...@na...> - 2013-07-29 16:39:01
|
Yes. I mean just header for .s file, so it should be equal to avr-gcc. For set_system_time.c gcc produces next header: .file "set_system_time.c" __SP_H__ = 0x3e __SP_L__ = 0x3d __SREG__ = 0x3f __tmp_reg__ = 0 __zero_reg__ = 1 ... Just compare our output and one generated by gcc (in attachment). Borja Ferrer wrote: > You mean in the header (top) of the .S file instead of the footer no? > > > 2013/7/29 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>> > > Currently I have found that set_system_time.c hardcodes __SREG__ and > __tmp_reg__ names in inlineasm. GCC just puts the footer for all .s > files: > __SP_H__ = 0x3e > __SP_L__ = 0x3d > __SREG__ = 0x3f > __tmp_reg__ = 0 > __zero_reg__ = 1 > > Can we do the same? > > -Stepan. > > Borja Ferrer wrote: > > Hello Stepan, > > 1) Yes, I'm aware of our double width definition in clang. I > have to do > some tests before changing it in clang and other places back to > 32bits, > so in the meantime it's ok to leave that change locally for you. > > 2) If I understand that code correctly they are setting SI to an > integer > type which is 16bits for our target. If that's the case, they > have to > take care of ints being smaller than 32 bits. They check in the > 64bit > case for the long type width and do it right there. So I would > say fill > in a bug report or send them a patch if you have the fix. > > Btw, if you want, create a branch in svn and add there all the > avrlibc > patches and stuff instead of getting them lost here in the > mailing list. > > > > 2013/7/29 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > > Currently I'm considering it as clang bug. In > handleModeAttr they > handle 'SI' as 32 bit value (that's ok for us, but instead > it should > be 4*QI), and what is really wrong for AVR is how 32 value > type is > handled here: > > case 32: > if (!IntegerMode) > NewTy = S.Context.FloatTy; > else if (OldTy->isSignedIntegerType()) > NewTy = S.Context.IntTy; > else > NewTy = S.Context.UnsignedIntTy; > > -Stepan. > > Stepan Dyatkovskiy wrote: > > Hi Borja, > > In clang/lib/Basic/Targets.cpp, > AVRTargetInfo::AVRTargetInfo()____, I have > > changed DoubleWidth to 32 bit value. Is it legal? I > mean why it > was 64 > bits, doesn't it has some pitfalls? Anyway I allowed me to > compile that > large source. > > > > typedef unsigned int uint32_t __attribute__ > ((__mode__ > > (__SI__))); > > I have found the next info about it > (http://www.delorie.com/gnu/____docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/__docs/gcc/gcc_80.html> > <http://www.delorie.com/gnu/__docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/docs/gcc/gcc_80.html>>): > > > QI -- An integer that is as wide as the smallest > addressable unit, > usually 8 bits. > HI -- An integer, twice as wide as a QI mode integer, > usually 16 > bits. > SI -- An integer, four times as wide as a QI mode integer, > usually 32 bits. > DI -- An integer, eight times as wide as a QI mode integer, > usually 64 > bits. > SF -- A floating point value, as wide as a SI mode integer, > usually 32 > bits. > DF -- A floating point value, as wide as a DI mode integer, > usually 64 bits. > > It is implemented in > clang/lib/Sema/SemaDeclAttr.____cpp, in > > handleModeAttr > static function. > > Perhaps we just have to sort it out in AVRTargetInfo... > > -Stepan. > > Borja Ferrer wrote: > > Found it, the isfinite() function takes in a > double, and > since our > backend treats them as 64bit types this fails in > inline asm. > Removing > the function implementation and just leaving it as > an extern > compiles > successfully. > > > 2013/7/28 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...>>__>__> > > I've tried different optimization levels and > they all > fail for me. > The interesting thing is that i've isolated > the strtod > function in a > different file and it compiles fine, so there's > something in the > huge file that causes this. > > > 2013/7/28 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...>>>> > > > > > > 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. > > Wow great. Never expected that wrong > definition. > > > > > Now im getting an error in llc: error: > couldn't > allocate > input reg for constraint 'r' > > > > Hm.. May be try with O2 instead of Os? > > > 2013/7/28 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...>>__>__> > > > >> 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... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto: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. > > > -- > Truly yours, > Stepan Dyatkovskiy > > > > > > > ------------------------------____----------------------------__--__------------------ > > > 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>> > ___________________________________________________ > avr-llvm-devel mailing list > avr-llvm-devel@lists.__sourcef__orge.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>> > > > > > |
