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