Re: [avr-llvm-devel] Inline assembly.

[Borja F. <bor...@gm...>]

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...>

> 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>
>> ):
>>
>> 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<http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk>
>> ______________________________**_________________
>> avr-llvm-devel mailing list
>> 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>
>>
>>
>