Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Stepan D. <stp...@na...> - 2013-07-29 18:22:18
|
Gotcha!!!
In output I send you patch for avr-libc.
Remained issues:
-- PR16712,
-- Bug with 'mode' attr in SemaDeclAttr, handleModeAttr function
-- AVRTargetInfo, size of double
-- AVRAsmPrinter, emit asm header.
-- By some strange reason avr-clang treats differently with 'int' and
int16_t (that is the same int, but with attribute added), so the next
one causes error:
int foo(); // header
int16_t foo() { return 0; } // .c file.
-- But currently (you will see in patch) I fixed their stdint.h.
-- I'm still using CCAS=avr-gcc
Though I think we already have solution for TargetInfo and AsmPrinter.
Configure command:
$AVR_LIBC_SRC/configure CC=$AVR_CLANG_BIN/avr-clang --build= --host=avr
CCAS=avr-gcc
-Stepan.
Borja Ferrer wrote:
> Yes, that's the way of doing it, thanks for the code, I will add it later.
>
> So how many files have you successfully compiled so far?
>
>
> 2013/7/29 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Just in case, I have already added temporary it in my sources. To do
> that you should implement AVRAsmPrinter::__EmitStartOfAsmFile method
> (that is virtual for AsmPrinter). Currently it looks like:
>
> void AVRAsmPrinter::__EmitStartOfAsmFile(Module &M) {
> // FIXME: Perhaps do it somehow with OutStreamer.EmitAssignment
> OutStreamer.EmitRawText(__StringRef(
> "__SP_H__ = 0x3e\n\t"
> "__SP_L__ = 0x3d\n\t"
> "__SREG__ = 0x3f\n\t"
> "__tmp_reg__ = 0\n\t"
> "__zero_reg__ = 1\n\t"
> ));
> }
>
>
> Borja Ferrer wrote:
>
> Ok yes I will add this tonight.
>
> El lunes, 29 de julio de 2013, Stepan Dyatkovskiy escribió:
>
> 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...>
> <mailto: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...>> <mailto: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>>
>
> <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>>>
>
>
>
> <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>>
>
> <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...>>__>
> <mailto: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...>>>
> <mailto: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...>>__>
>
> <mailto: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...>>__>
>
> <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,
> >>>
> >>> 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" \
>
>
>
|
