From: Stepan D. <stp...@na...> - 2013-07-29 13:46:56
|
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): > > 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...>> >> >> 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...>> >> >> >> >> > 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...>> >> > >> >> 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...>> >> >> >> >>> 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 > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > |