Menu
▾
▴
avr-llvm-devel — Developers mailing list.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(26) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(14) |
Oct
(16) |
Nov
(36) |
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(17) |
May
(9) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(4) |
| 2012 |
Jan
(22) |
Feb
(12) |
Mar
(39) |
Apr
(31) |
May
(42) |
Jun
(35) |
Jul
(32) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(9) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(121) |
Jul
(61) |
Aug
(7) |
Sep
(8) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Stepan D. <stp...@na...> - 2013-07-29 18:58:20
|
Borja Ferrer wrote:
> WOW!!! very nice :)
>
> 1) Is the issue with int16_t related to what we discovered yesterday? So
> is sizeof(int) == sizeof(int16_t) true?
Yes its true. It is different issue. It just treats attributed int and
just-int as different types.
> 3) Commit this patch to SVN, and create a new directory for it, John any
> suggestions about the dir structure for this?
My suggestion is still to use GIT. From moment I started to work on
inlineasm I kept everything in GIT on github, syncing with your svn repo
from time to time.
> 2) What sort of errors do you get without setting the CCAS line? Again,
> avr-clang should call avr-as if it's in the $PATH.
I wrote you few days ago (it is not for avr2, I found this fires for
avr5 as well):
>
> About compiling avrlibc:
>
> >> Also avr-clang emits wrong sequense for .S files. So I'm using
> CCAS=avr-gcc.
> What do you mean with this? What is wrong?
Directory:
bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/at90s1200
bash:$ avr-clang -DHAVE_CONFIG_H -I.
-I../../../../../avr-libc/avr/lib/avr2/at90s1200 -I../../../..
-I../../../../../avr-libc/common -I../../../../../avr-libc/include
-I../../../../include -I../../../../../avr-libc/common
-I../../../../../avr-libc/include -I../../../../include -x
assembler-with-cpp -mmcu=at90s1200 -DIOSYMFILE=\"iosym/at90s1200.S\"
-MT gcrt1.o -MD -MP -MF .deps/gcrt1.Tpo -c -o gcrt1.o
../../../../../avr-libc/crt1/gcrt1.S
tons of errors.
I suppose thats because clang driver uses different tools for asm files.
For the -### command avr-clang shows the next:
"avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free"
"-main-file-name" "gcrt1.S" "-mrelocation-model" "static"
"-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases"
"-target-linker-version" "2.22.90.20120924" "-coverage-file"
"/tmp/gcrt1-fecbe5.s" "-resource-dir"
"/media/stepan/workproj/llvm.project/2-avr/builds/llvm.debug-avr-arm-x86_64.build/Debug+Asserts/bin/../lib/clang/3.4"
"-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps" "-MP" "-MT"
"gcrt1.o" "-D" "HAVE_CONFIG_H" "-D" "IOSYMFILE=\"iosym/at90s1200.S\""
"-I" "." "-I" "../../../../../avr-libc/avr/lib/avr2/at90s1200" "-I"
"../../../.." "-I" "../../../../../avr-libc/common" "-I"
"../../../../../avr-libc/include" "-I" "../../../../include" "-I"
"../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include"
"-I" "../../../../include" "-fno-dwarf-directory-asm"
"-fdebug-compilation-dir"
"/media/stepan/workproj/llvm.project/2-avr/avr-libc/trunk/build.opt/avr/lib/avr2/at90s1200"
"-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign"
"-fobjc-runtime=gcc" "-fobjc-default-synthesize-properties"
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops"
"-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp"
"../../../../../avr-libc/crt1/gcrt1.S"
"/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I"
"../../../../../avr-libc/avr/lib/avr2/at90s1200" "-I" "../../../.." "-I"
"../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include"
"-I" "../../../../include" "-I" "../../../../../avr-libc/common" "-I"
"../../../../../avr-libc/include" "-I" "../../../../include"
"-mmcu=at90s1200" "-D" "IOSYMFILE=\"iosym/at90s1200.S\"" "-MT" "gcrt1.o"
"-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o" "gcrt1.o" "-x" "assembler"
"/tmp/gcrt1-fecbe5.s"
While avr-gcc uses next sequence:
/usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I
../../../../../avr-libc/avr/lib/avr2/at90s1200 -I ../../../.. -I
../../../../../avr-libc/common -I ../../../../../avr-libc/include -I
../../../../include -I ../../../../../avr-libc/common -I
../../../../../avr-libc/include -I ../../../../include -MD gcrt1.d -MF
.deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D
"IOSYMFILE=\"iosym/at90s1200.S\"" ../../../../../avr-libc/crt1/gcrt1.S
"-mmcu=at90s1200" -fno-directives-only -o /tmp/ccK7jMC3.s
'-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"' '-MT' 'gcrt1.o'
'-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o' 'gcrt1.o'
/usr/lib/gcc/avr/4.7.0/../../../avr/bin/as "-mmcu=at90s1200"
-mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s
> 3) Commit this patch to SVN, and create a new directory for it, John any
> suggestions about the dir structure for this?
>
> I will fix those two issues later, we still need to fix or report the
> mode thing though.
>
>
>
> 2013/7/29 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Stepan Dyatkovskiy wrote:
>
> Gotcha!!!
>
> I mean, I have compiled it successfully :-)
>
>
> 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...>
> <mailto: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...>>
> <mailto: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...>>> <mailto: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>>>>
>
>
>
>
> <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...>>__>__>
>
> <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...
> <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...>>>>
>
> <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...
> <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...>>__>__>
>
> <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...
> <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...>>__>__>
>
> <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...
> <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" \
>
>
>
>
>
>
> ------------------------------__------------------------------__------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases
> havent
> caught up. So what steps can you take to put your SQL databases
> under
> version control? Why should you start doing it? Read more to
> find out.
> http://pubads.g.doubleclick.__net/gampad/clk?id=49501711&iu=__/4140/ostg.clktrk
> <http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk>
>
>
>
>
> _________________________________________________
> avr-llvm-devel mailing list
> 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>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-29 18:52:03
|
WOW!!! very nice :)
1) Is the issue with int16_t related to what we discovered yesterday? So is
sizeof(int) == sizeof(int16_t) true?
2) What sort of errors do you get without setting the CCAS line? Again,
avr-clang should call avr-as if it's in the $PATH.
3) Commit this patch to SVN, and create a new directory for it, John any
suggestions about the dir structure for this?
I will fix those two issues later, we still need to fix or report the mode
thing though.
2013/7/29 Stepan Dyatkovskiy <stp...@na...>
> Stepan Dyatkovskiy wrote:
>
>> Gotcha!!!
>>
> I mean, I have compiled it successfully :-)
>
>
>> 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>
>>> >>>
>>>
>>>
>>>
>>> <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" \
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------**------------------------------**
>> ------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> http://pubads.g.doubleclick.**net/gampad/clk?id=49501711&iu=**
>> /4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=49501711&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>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-29 18:32:55
|
Stepan Dyatkovskiy wrote:
> Gotcha!!!
I mean, I have compiled it successfully :-)
>
> 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" \
>>
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
|
|
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" \
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-29 17:04:10
|
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...>
> 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...>>
>>
>> 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>
>> >
>> <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...>**>__>__>
>>
>> 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" \
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-29 16:56:34
|
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...>>
>
> 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>>
>
> <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" \
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-29 16:48:12
|
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... >> >> >> >> 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> >> > >> <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" \ >> > > |
|
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>> > > > > > |
|
From: Borja F. <bor...@gm...> - 2013-07-29 16:33:51
|
You mean in the header (top) of the .S file instead of the footer no? 2013/7/29 Stepan Dyatkovskiy <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... >> >> >> >> >> 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...>* >> *>__> >> >> 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...>>> >> >> >> >> >> > 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...>**>__> >> > >> >> 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...>**>__> >> >> >> >>> 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<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> >> > >> >> >> >> > |
|
From: Stepan D. <stp...@na...> - 2013-07-29 16:17:07
|
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...>> > > 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...> > <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...>>> > > > > > 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...>>__> > > > >> 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...>>__> > >> > >>> 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 > <mailto:avr...@li...> > https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> > > > |
|
From: Borja F. <bor...@gm...> - 2013-07-29 14:33:07
|
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> >> >> > |
|
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
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-29 13:39:31
|
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 > > > |
|
From: Borja F. <bor...@gm...> - 2013-07-28 21:35:36
|
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...>
> 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...>
>
>>
>>
>> > 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...>
>> >
>> >> 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...>
>> >>
>> >>> 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
>>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 19:46:57
|
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...>
>
>
> > 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...>
> >
> >> 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...>
> >>
> >>> 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
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-28 19:16:54
|
> 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...>
>
>> 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...>
>>
>>> 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
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 18:37:18
|
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.
Now im getting an error in llc: error: couldn't allocate input reg for
constraint 'r'
2013/7/28 Borja Ferrer <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...>
>
>> 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.
>>
>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-28 18:36:19
|
Exactly. You got assertion due to incorrect inlineasm instruction. I had also failed to reproduce this behavoiur for reduced case. This bug fired for big source only. Try compile that big source with -emit-llvm, and lookup inline asm (there is some variable with name, that ends with "m10", perhaps you recheck that name in .c file). I can attach result IR file with string number reference a bit later, currently I'm stucking in traffic jam :-(
-Stepan
> 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...>
>
>> 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
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 16:57:33
|
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...>
> 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.
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 16:46:29
|
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.
|
|
From: Stepan D. <stp...@na...> - 2013-07-27 14:48:46
|
Hi Borja,
> Currently I'm learning avr-libc configs. How did you restrict to
> compile it for avr5 only?
Ah, never mind. I've managed with that issue. Now I got more serious one.
Next inline asm:
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"
);
Is converted to:
%18 = tail call { i16, i16 } asm sideeffect
"lpm\0A\09
mov ${0:A}, r0\0A\09
adiw r30, 1\0A\09lpm\0A\09
mov ${0:B}, r0\0A\09
adiw r30, 1\0A\09
lpm\0A\09
mov ${0:C}, r0\0A\09
adiw r30, 1\0A\09
lpm\0A\09
mov ${0:D}, r0\0A\09", "=r,=z,1,~{r0}"(i16 %17) #7, !srcloc !3
Note __result (that is 32 bit value) was truncated to i16.
So output IR inline asm instruction become incorrect.
I attached the source with issue. I didn't reduce it yet. Issue seems to
be at string #8633, in pgm_read_dword macro.
Try to compile it with command:
./avr-clang inline-asm-multibyte3X.c -S -o - -Os
Currently it is crashed. I wanna take a rest a bit. Though may be you
have some ideas.
-Stepan.
Borja Ferrer wrote:
> Restrict where? In avrlibc or llvm?
>
> El sábado, 27 de julio de 2013, Stepan Dyatkovskiy escribió:
>
> Currently I'm learning avr-libc configs. How did you restrict to
> compile it for avr5 only?
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Ok I will take a look at that 01 character to see from where
> it's coming
> from.
>
> About the other issue, it's weird, i've managed to build a huge
> c file
> with avr-clang with no errors. Since i have avr-as and the rest
> of avr
> binutils in my PATH, avr-clang calls them automatically to
> assemble and
> link the program. The only thing i MUST do is pass mmcu=avr5
> otherwise i
> get all those movw errors in the assembler. Remember to
> configure LLVM
> with the --target, --host, etc options to build it as a cross
> compiler.
>
> I'm also seeing a lot of references to avr2 and the at90s120 inside
> those cmd lines, I dont know if this makes any difference but
> again, we
> cant compile for those mcus now.
>
>
>
> 2013/7/26 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...>>
>
> Borja Ferrer wrote:
>
> Hello Stepan,
>
> No problem with those fixes :)
>
>
> 2) It's interesting we get different IR, can you
> explain more
> what is
> going on here? This is the last bit of inline asm
> support, the
> sooner we
> fix it the better so we can move on to more interesting
> things.
>
>
> For next example:
>
> int a,b;
> extern long Calc(void) asm ("CALCULATE");
> void f() { Calc(); }
>
> avr-clang emits:
>
> ; some header
> ; Function Attrs: noinline nounwind
> define void @f() #0 {
> entry:
> %call = call i32 @"\01CALCULATE"() ; Stepan: note \01
> character.
> ret void
> }
> declare i32 @"\01CALCULATE"() #1
> ; some footer
>
> arm-linux-gnueabi emits:
>
> ; some header
> ; Function Attrs: nounwind
> define void @f() #0 {
> entry:
> %call = call i32 @CALCULATE() ; Stepan: no \01 character.
> ret void
> }
> declare i32 @CALCULATE() #1
> ;some footer
>
> But .S files looks fine. No \01 characters anywhere.
>
>
>
> About compiling avrlibc:
>
> >> Also avr-clang emits wrong sequense for .S files.
> So I'm using
> CCAS=avr-gcc.
> What do you mean with this? What is wrong?
>
> Directory:
> bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/____at90s1200
> bash:$ avr-clang -DHAVE_CONFIG_H -I.
> -I../../../../../avr-libc/avr/____lib/avr2/at90s1200
> -I../../../..
> -I../../../../../avr-libc/____common
> -I../../../../../avr-libc/____include -I../../../../include
> -I../../../../../avr-libc/____common
> -I../../../../../avr-libc/____include -I../../../../include -x
> assembler-with-cpp -mmcu=at90s1200
> -DIOSYMFILE=\"iosym/at90s1200.____S\" -MT gcrt1.o -MD
> -MP -MF
> .deps/gcrt1.Tpo -c -o gcrt1.o
> ../../../../../avr-libc/crt1/____gcrt1.S
>
> tons of errors.
>
> I suppose thats because clang driver uses different tools
> for asm files.
>
> For the -### command avr-clang shows the next:
>
> "avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free"
> "-main-file-name" "gcrt1.S" "-mrelocation-model" "static"
> "-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases"
> "-target-linker-version" "2.22.90.20120924" "-coverage-file"
> "/tmp/gcrt1-fecbe5.s" "-resource-dir"
>
> "/media/stepan/workproj/llvm.____project/2-avr/builds/llvm.____debug-avr-arm-x86_64.build/____Debug+Asserts/bin/../lib/____clang/3.4"
> "-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps"
> "-MP" "-MT"
> "gcrt1.o" "-D" "HAVE_CONFIG_H" "-D"
> "IOSYMFILE=\"iosym/at90s1200.____S\"" "-I" "." "-I"
> "../../../../../avr-libc/avr/____lib/avr2/at90s1200" "-I"
> "../../../.." "-I" "../../../../../avr-libc/____common" "-I"
> "../../../../../avr-libc/____include" "-I"
> "../../../../include" "-I"
> "../../../../../avr-libc/____common" "-I"
> "../../../../../avr-libc/____include" "-I"
> "../../../../include"
> "-fno-dwarf-directory-asm" "-fdebug-compilation-dir"
>
> "/media/stepan/workproj/llvm.____project/2-avr/avr-libc/trunk/____build.opt/avr/lib/avr2/____at90s1200"
> "-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign"
> "-fobjc-runtime=gcc" "-fobjc-default-synthesize-____properties"
> "-fdiagnostics-show-option" "-fcolor-diagnostics"
> "-vectorize-loops"
> "-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp"
> "../../../../../avr-libc/crt1/____gcrt1.S"
>
> "/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I"
> "../../../../../avr-libc/avr/____lib/avr2/at90s1200" "-I"
> "../../../.." "-I" "../../../../../avr-libc/____common" "-I"
> "../../../../../avr-libc/____include" "-I"
> "../../../../include" "-I"
> "../../../../../avr-libc/____common" "-I"
> "../../../../../avr-libc/____include" "-I"
> "../../../../include"
> "-mmcu=at90s1200" "-D"
> "IOSYMFILE=\"iosym/at90s1200.____S\"" "-MT"
> "gcrt1.o" "-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o"
> "gcrt1.o"
> "-x" "assembler" "/tmp/gcrt1-fecbe5.s"
>
> While avr-gcc uses next sequence:
>
> /usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I
> ../../../../../avr-libc/avr/____lib/avr2/at90s1200 -I
> ../../../.. -I
> ../../../../../avr-libc/common -I
> ../../../../../avr-libc/____include
> -I ../../../../include -I ../../../../../avr-libc/common -I
> ../../../../../avr-libc/____include -I ../../../../include
> -MD gcrt1.d
> -MF .deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D
> "IOSYMFILE=\"iosym/at90s1200.____S\""
> ../../../../../avr-libc/crt1/____gcrt1.S "-mmcu=at90s1200"
> -fno-directives-only -o /tmp/ccK7jMC3.s
> '-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"____'
> '-MT'
> 'gcrt1.o' '-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o'
> 'gcrt1.o'
>
> /usr/lib/gcc/avr/4.7.0/../../.____./avr/bin/as
> "-mmcu=at90s1200"
> -mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s
>
>
>
>
> 2) Since I compile clang as a cross compiler this is not a
> problem for
> me, all llvm binaries are prefixed with avr.
>
> >> Currently compilation stopped with unsupported movw
> instruction for
> avr2.
> Yes, this is going to be a problem. Try to modify the build
> scripts to
> compile everything for mmcu=avr5. We don't support any
> smaller
> devices.
>
>
> OK. Will do.
>
> -Stepan
>
>
>
>
> 2013/7/26 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
>
> Hello Borja,
>
> Thanks for fixes! Especially my stupid pieces of
> code in
> AVRAsmPrinter.cpp
>
>
> Back to your post at 01.07.2013:
>
> You wrote:
> [quote]
> Yes but the first goal now is to have inline asm
> feature
> complete xD
> Then we can move into other places of the library.
>
> Taking a look at the previous emails this is what
> needs
> still to be
> done:
> 1) Implement the missed optimization above for the
> memory
> constraint.
> Also see if you can come with further cases.
> Remember to
> add a test
> case.
> 2) Implement the stuff in the "C names used in
> assembler
> code" section
> of the avrlibc manual. You mentioned some issues
> here in a
> previous
> email.
> 3) Implement the a0, a1, etc... constraints.
> [/quote]
>
> 1. Done.
> 2. I checked it again. It works, though way of IR
> generation differs
> from ARM back-end for example.
> 3. Done.
>
> Now, I suppose, we have to work more with clang.
> But it is
> difficult
> since our changes are presented as patches.
>
> I had tried to compile avr-libc again. I had found
> clang
> bug (generic
> one: mistreating with builtins):
>
> http://llvm.org/bugs/show_bug.______cgi?id=16712
> <http://llvm.org/bugs/show_bug.____cgi?id=16712>
> <http://llvm.org/bugs/show___bug.__cgi?id=16712
> <http://llvm.org/bugs/show_bug.__cgi?id=16712>>
>
> <http://llvm.org/bugs/show_____bug.cgi?id=16712
> <http://llvm.org/bugs/show___bug.cgi?id=16712>
> <http://llvm.org/bugs/show___bug.cgi?id=16712
> <http://llvm.org/bugs/show_bug.cgi?id=16712>>>
>
> Also avr-clang emits wrong sequense for .S files.
> So I'm using
> CCAS=avr-gcc.
>
> Steps for avr-libc compilation:
>
> 0. I'm working with avr-libc, svn r2403.
>
> 1. We also need to apply several changes for it
> (see the
> patch in
> attachment).
>
> 2. Currently you should rename "clang" with
> "avr-clang".
> "ln -s" doesn't
> works. 'avr-gcc' name was hard-coded in
> configure.ac <http://configure.ac>
> <http://configure.ac>
> <http://configure.ac>, so I did the same
>
> with 'avr-clang'.
>
> 3. Run configure script as below:
> $AVR_LIBC_DIR/configure CC=$LLVM_BIN_DIR/avr-clang
> --build=
> --host=avr
> CCAS=avr-gcc
>
> A have also attached my config.log file.
>
> Currently compilation stopped with unsupported movw
> instruction for
> avr2.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Ok, you can commit the patch now.
>
>
> 2013/7/24 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...>>>>
>
> Borja Ferrer wrote:
>
> 1) I agree.
>
>
> 3) What happens when you use multibyte
> constraints with
> "e" or "b".
>
> Just had checked it. It works :-) Though
> I'll add
> test-cases for
> them too.
>
>
> 4) Hah ok, btw no need to check for i64?
>
> In one of our previous mails we decided to
> restrict i64
> usage, since
> avr-gcc doesn't support it properly.
>
> -Stepan
>
>
>
> 2013/7/24 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...>>>>>
>
> Hi Borja,
>
>
> > 1) You implemented the "aN"
> constraint
> by also
> allowing
> b,c,d
> > constraints. I'm not sure if gcc
> implements
> this, my
> guess is
> that only
> > "a" is needed. Please check
> to see
> what gcc
> does here.
>
> For b,c,d avr-gcc acts like it
> meet %a. I
> think
> its wrong and
> untested behaviour, so I just
> restricted
> usage to
> single
> 'a' character.
>
>
> > 2) Make getAlternativeRegName
> return a
> char
> instead of a
> string
> since we
> > only need to return one letter.
>
> Done
>
>
> > 3) Related to the changes in
> AVRISelLowering.cpp, do we
> need to care
> > about more register
> constraints apart
> of the
> ones you
> already
> covered?
>
> What you mean? I think all
> constraints
> are covered
> now. If
> no, we
> can find out it during
> compilation (avr-libc,
> arduino, etc).
>
>
> > 4) Now that wider types have
> been covered,
> please check
> if the
> assert I
> > commented out in
> AVRISelLowering.cpp
> in the
> inline asm
> code can be
> > removed or what.
>
> I replaced this assertion with
> error message.
> Suppose its
> better
> than killing the compiler :-)
>
> New patch is attached.
>
> -Stepan.
>
>
> Borja Ferrer wrote:
>
> Hello Stepan,
> The patch looks good, but I
> have some
> questions/comments:
>
> 1) You implemented the "aN"
> constraint by also
> allowing
> b,c,d
> constraints. I'm not sure if gcc
> implements
> this, my
> guess is
> that only
> "a" is needed. Please check
> to see
> what gcc
> does here.
> 2) Make
> getAlternativeRegName return
> a char
> instead of
> a string
> since we
> only need to return one letter.
> 3) Related to the changes in
> AVRISelLowering.cpp, do we
> need to care
> about more register
> constraints apart
> of the
> ones you
> already
> covered?
> 4) Now that wider types have
> been
> covered,
> please check
> if the
> assert I
> commented out in
> AVRISelLowering.cpp
> in the
> inline asm
> code can be
> removed or what.
>
>
>
> 2013/7/24 Stepan Dyatkovskiy
> <stp...@na... <mailto:stpworld@narod.r
> <mailto:stp...@na...
> <mailto:stp...@na...>>>>>>
>
>
> Hello Borja,
> Here is the new patch
> for multibyte
> reference.
> Please look
> at new
> tests to see what was
> implemented exactly.
> To fix issue I
> described in previous
> letter I've
> added new reg
> classes that contains
> pairs of 8 bit
> registers:
> If we pass i32
> parameter that
> should be
> split onto
> four 8
> bit regs,
> we set i16 register
> class first,
> then it
> would be
> replaced
> with 8
> bit registers if needed.
> Currently I see
> it is the
> only
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-27 14:10:57
|
Restrict where? In avrlibc or llvm?
El sábado, 27 de julio de 2013, Stepan Dyatkovskiy escribió:
> Currently I'm learning avr-libc configs. How did you restrict to compile
> it for avr5 only?
>
> -Stepan.
>
> Borja Ferrer wrote:
>
>> Ok I will take a look at that 01 character to see from where it's coming
>> from.
>>
>> About the other issue, it's weird, i've managed to build a huge c file
>> with avr-clang with no errors. Since i have avr-as and the rest of avr
>> binutils in my PATH, avr-clang calls them automatically to assemble and
>> link the program. The only thing i MUST do is pass mmcu=avr5 otherwise i
>> get all those movw errors in the assembler. Remember to configure LLVM
>> with the --target, --host, etc options to build it as a cross compiler.
>>
>> I'm also seeing a lot of references to avr2 and the at90s120 inside
>> those cmd lines, I dont know if this makes any difference but again, we
>> cant compile for those mcus now.
>>
>>
>>
>> 2013/7/26 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...
>> >>
>>
>> Borja Ferrer wrote:
>>
>> Hello Stepan,
>>
>> No problem with those fixes :)
>>
>>
>> 2) It's interesting we get different IR, can you explain more
>> what is
>> going on here? This is the last bit of inline asm support, the
>> sooner we
>> fix it the better so we can move on to more interesting things.
>>
>>
>> For next example:
>>
>> int a,b;
>> extern long Calc(void) asm ("CALCULATE");
>> void f() { Calc(); }
>>
>> avr-clang emits:
>>
>> ; some header
>> ; Function Attrs: noinline nounwind
>> define void @f() #0 {
>> entry:
>> %call = call i32 @"\01CALCULATE"() ; Stepan: note \01 character.
>> ret void
>> }
>> declare i32 @"\01CALCULATE"() #1
>> ; some footer
>>
>> arm-linux-gnueabi emits:
>>
>> ; some header
>> ; Function Attrs: nounwind
>> define void @f() #0 {
>> entry:
>> %call = call i32 @CALCULATE() ; Stepan: no \01 character.
>> ret void
>> }
>> declare i32 @CALCULATE() #1
>> ;some footer
>>
>> But .S files looks fine. No \01 characters anywhere.
>>
>>
>>
>> About compiling avrlibc:
>>
>> >> Also avr-clang emits wrong sequense for .S files. So I'm
>> using
>> CCAS=avr-gcc.
>> What do you mean with this? What is wrong?
>>
>> Directory:
>> bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/__**at90s1200
>> bash:$ avr-clang -DHAVE_CONFIG_H -I.
>> -I../../../../../avr-libc/avr/**__lib/avr2/at90s1200 -I../../../..
>> -I../../../../../avr-libc/__**common
>> -I../../../../../avr-libc/__**include -I../../../../include
>> -I../../../../../avr-libc/__**common
>> -I../../../../../avr-libc/__**include -I../../../../include -x
>> assembler-with-cpp -mmcu=at90s1200
>> -DIOSYMFILE=\"iosym/at90s1200.**__S\" -MT gcrt1.o -MD -MP -MF
>> .deps/gcrt1.Tpo -c -o gcrt1.o ../../../../../avr-libc/crt1/_**
>> _gcrt1.S
>>
>> tons of errors.
>>
>> I suppose thats because clang driver uses different tools for asm
>> files.
>>
>> For the -### command avr-clang shows the next:
>>
>> "avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free"
>> "-main-file-name" "gcrt1.S" "-mrelocation-model" "static"
>> "-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases"
>> "-target-linker-version" "2.22.90.20120924" "-coverage-file"
>> "/tmp/gcrt1-fecbe5.s" "-resource-dir"
>> "/media/stepan/workproj/llvm._**_project/2-avr/builds/llvm.__**
>> debug-avr-arm-x86_64.build/__**Debug+Asserts/bin/../lib/__**clang/3.4"
>> "-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps" "-MP" "-MT"
>> "gcrt1.o" "-D" "HAVE_CONFIG_H" "-D"
>> "IOSYMFILE=\"iosym/at90s1200._**_S\"" "-I" "." "-I"
>> "../../../../../avr-libc/avr/_**_lib/avr2/at90s1200" "-I"
>> "../../../.." "-I" "../../../../../avr-libc/__**common" "-I"
>> "../../../../../avr-libc/__**include" "-I" "../../../../include" "-I"
>> "../../../../../avr-libc/__**common" "-I"
>> "../../../../../avr-libc/__**include" "-I" "../../../../include"
>> "-fno-dwarf-directory-asm" "-fdebug-compilation-dir"
>> "/media/stepan/workproj/llvm._**_project/2-avr/avr-libc/trunk/**
>> __build.opt/avr/lib/avr2/__**at90s1200"
>> "-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign"
>> "-fobjc-runtime=gcc" "-fobjc-default-synthesize-__**properties"
>> "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops"
>> "-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp"
>> "../../../../../avr-libc/crt1/**__gcrt1.S"
>>
>> "/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I"
>> "../../../../../avr-libc/avr/_**_lib/avr2/at90s1200" "-I"
>> "../../../.." "-I" "../../../../../avr-libc/__**common" "-I"
>> "../../../../../avr-libc/__**include" "-I" "../../../../include" "-I"
>> "../../../../../avr-libc/__**common" "-I"
>> "../../../../../avr-libc/__**include" "-I" "../../../../include"
>> "-mmcu=at90s1200" "-D" "IOSYMFILE=\"iosym/at90s1200._**_S\"" "-MT"
>> "gcrt1.o" "-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o" "gcrt1.o"
>> "-x" "assembler" "/tmp/gcrt1-fecbe5.s"
>>
>> While avr-gcc uses next sequence:
>>
>> /usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I
>> ../../../../../avr-libc/avr/__**lib/avr2/at90s1200 -I ../../../.. -I
>> ../../../../../avr-libc/common -I ../../../../../avr-libc/__**include
>> -I ../../../../include -I ../../../../../avr-libc/common -I
>> ../../../../../avr-libc/__**include -I ../../../../include -MD
>> gcrt1.d
>> -MF .deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D
>> "IOSYMFILE=\"iosym/at90s1200._**_S\""
>> ../../../../../avr-libc/crt1/_**_gcrt1.S "-mmcu=at90s1200"
>> -fno-directives-only -o /tmp/ccK7jMC3.s
>> '-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"**__' '-MT'
>> 'gcrt1.o' '-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o' 'gcrt1.o'
>>
>> /usr/lib/gcc/avr/4.7.0/../../.**__./avr/bin/as "-mmcu=at90s1200"
>> -mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s
>>
>>
>>
>>
>> 2) Since I compile clang as a cross compiler this is not a
>> problem for
>> me, all llvm binaries are prefixed with avr.
>>
>> >> Currently compilation stopped with unsupported movw
>> instruction for
>> avr2.
>> Yes, this is going to be a problem. Try to modify the build
>> scripts to
>> compile everything for mmcu=avr5. We don't support any smaller
>> devices.
>>
>>
>> OK. Will do.
>>
>> -Stepan
>>
>>
>>
>>
>> 2013/7/26 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>> <mailto:stp...@na...>>>
>>
>>
>> Hello Borja,
>>
>> Thanks for fixes! Especially my stupid pieces of code in
>> AVRAsmPrinter.cpp
>>
>>
>> Back to your post at 01.07.2013:
>>
>> You wrote:
>> [quote]
>> Yes but the first goal now is to have inline asm feature
>> complete xD
>> Then we can move into other places of the library.
>>
>> Taking a look at the previous emails this is what needs
>> still to be
>> done:
>> 1) Implement the missed optimization above for the memory
>> constraint.
>> Also see if you can come with further cases. Remember to
>> add a test
>> case.
>> 2) Implement the stuff in the "C names used in assembler
>> code" section
>> of the avrlibc manual. You mentioned some issues here in a
>> previous
>> email.
>> 3) Implement the a0, a1, etc... constraints.
>> [/quote]
>>
>> 1. Done.
>> 2. I checked it again. It works, though way of IR
>> generation differs
>> from ARM back-end for example.
>> 3. Done.
>>
>> Now, I suppose, we have to work more with clang. But it is
>> difficult
>> since our changes are presented as patches.
>>
>> I had tried to compile avr-libc again. I had found clang
>> bug (generic
>> one: mistreating with builtins):
>>
>> http://llvm.org/bugs/show_bug.**____cgi?id=16712<http://llvm.org/bugs/show_bug.____cgi?id=16712>
>> <http://llvm.org/bugs/show_**bug.__cgi?id=16712<http://llvm.org/bugs/show_bug.__cgi?id=16712>
>> >
>>
>> <http://llvm.org/bugs/show___**bug.cgi?id=16712<http://llvm.org/bugs/show___bug.cgi?id=16712>
>> <http://llvm.org/bugs/show_**bug.cgi?id=16712<http://llvm.org/bugs/show_bug.cgi?id=16712>
>> >>
>>
>> Also avr-clang emits wrong sequense for .S files. So I'm
>> using
>> CCAS=avr-gcc.
>>
>> Steps for avr-libc compilation:
>>
>> 0. I'm working with avr-libc, svn r2403.
>>
>> 1. We also need to apply several changes for it (see the
>> patch in
>> attachment).
>>
>> 2. Currently you should rename "clang" with "avr-clang".
>> "ln -s" doesn't
>> works. 'avr-gcc' name was hard-coded in configure.ac
>> <http://configure.ac>
>> <http://configure.ac>, so I did the same
>>
>> with 'avr-clang'.
>>
>> 3. Run configure script as below:
>> $AVR_LIBC_DIR/configure CC=$LLVM_BIN_DIR/avr-clang --build=
>> --host=avr
>> CCAS=avr-gcc
>>
>> A have also attached my config.log file.
>>
>> Currently compilation stopped with unsupported movw
>> instruction for
>> avr2.
>>
>> -Stepan.
>>
>> Borja Ferrer wrote:
>>
>> Ok, you can commit the patch now.
>>
>>
>> 2013/7/24 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...>>>>
>>
>> Borja Ferrer wrote:
>>
>> 1) I agree.
>>
>>
>> 3) What happens when you use multibyte
>> constraints with
>> "e" or "b".
>>
>> Just had checked it. It works :-) Though I'll add
>> test-cases for
>> them too.
>>
>>
>> 4) Hah ok, btw no need to check for i64?
>>
>> In one of our previous mails we decided to
>> restrict i64
>> usage, since
>> avr-gcc doesn't support it properly.
>>
>> -Stepan
>>
>>
>>
>> 2013/7/24 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...>>>>>
>>
>> Hi Borja,
>>
>>
>> > 1) You implemented the "aN" constraint
>> by also
>> allowing
>> b,c,d
>> > constraints. I'm not sure if gcc
>> implements
>> this, my
>> guess is
>> that only
>> > "a" is needed. Please check to see
>> what gcc
>> does here.
>>
>> For b,c,d avr-gcc acts like it meet %a. I
>> think
>> its wrong and
>> untested behaviour, so I just restricted
>> usage to
>> single
>> 'a' character.
>>
>>
>> > 2) Make getAlternativeRegName return a
>> char
>> instead of a
>> string
>> since we
>> > only need to return one letter.
>>
>> Done
>>
>>
>> > 3) Related to the changes in
>> AVRISelLowering.cpp, do we
>> need to care
>> > about more register constraints apart
>> of the
>> ones you
>> already
>> covered?
>>
>> What you mean? I think all constraints
>> are covered
>> now. If
>> no, we
>> can find out it during compilation
>> (avr-libc,
>> arduino, etc).
>>
>>
>> > 4) Now that wider types have been
>> covered,
>> please check
>> if the
>> assert I
>> > commented out in AVRISelLowering.cpp
>> in the
>> inline asm
>> code can be
>> > removed or what.
>>
>> I replaced this assertion with error
>> message.
>> Suppose its
>> better
>> than killing the compiler :-)
>>
>> New patch is attached.
>>
>> -Stepan.
>>
>>
>> Borja Ferrer wrote:
>>
>> Hello Stepan,
>> The patch looks good, but I have some
>> questions/comments:
>>
>> 1) You implemented the "aN"
>> constraint by also
>> allowing
>> b,c,d
>> constraints. I'm not sure if gcc
>> implements
>> this, my
>> guess is
>> that only
>> "a" is needed. Please check to see
>> what gcc
>> does here.
>> 2) Make getAlternativeRegName return
>> a char
>> instead of
>> a string
>> since we
>> only need to return one letter.
>> 3) Related to the changes in
>> AVRISelLowering.cpp, do we
>> need to care
>> about more register constraints apart
>> of the
>> ones you
>> already
>> covered?
>> 4) Now that wider types have been
>> covered,
>> please check
>> if the
>> assert I
>> commented out in AVRISelLowering.cpp
>> in the
>> inline asm
>> code can be
>> removed or what.
>>
>>
>>
>> 2013/7/24 Stepan Dyatkovskiy
>> <stp...@na... <mailto:stpworld@narod.r
>> <mailto:stp...@na... <mailto:stp...@na...>>>>>>
>>
>>
>> Hello Borja,
>> Here is the new patch for
>> multibyte
>> reference.
>> Please look
>> at new
>> tests to see what was
>> implemented exactly.
>> To fix issue I described in
>> previous
>> letter I've
>> added new reg
>> classes that contains pairs of 8
>> bit
>> registers:
>> If we pass i32 parameter that
>> should be
>> split onto
>> four 8
>> bit regs,
>> we set i16 register class first,
>> then it
>> would be
>> replaced
>> with 8
>> bit registers if needed.
>> Currently I see
>> it is the
>> only
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-27 11:12:49
|
Currently I'm learning avr-libc configs. How did you restrict to compile
it for avr5 only?
-Stepan.
Borja Ferrer wrote:
> Ok I will take a look at that 01 character to see from where it's coming
> from.
>
> About the other issue, it's weird, i've managed to build a huge c file
> with avr-clang with no errors. Since i have avr-as and the rest of avr
> binutils in my PATH, avr-clang calls them automatically to assemble and
> link the program. The only thing i MUST do is pass mmcu=avr5 otherwise i
> get all those movw errors in the assembler. Remember to configure LLVM
> with the --target, --host, etc options to build it as a cross compiler.
>
> I'm also seeing a lot of references to avr2 and the at90s120 inside
> those cmd lines, I dont know if this makes any difference but again, we
> cant compile for those mcus now.
>
>
>
> 2013/7/26 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Borja Ferrer wrote:
>
> Hello Stepan,
>
> No problem with those fixes :)
>
>
> 2) It's interesting we get different IR, can you explain more
> what is
> going on here? This is the last bit of inline asm support, the
> sooner we
> fix it the better so we can move on to more interesting things.
>
>
> For next example:
>
> int a,b;
> extern long Calc(void) asm ("CALCULATE");
> void f() { Calc(); }
>
> avr-clang emits:
>
> ; some header
> ; Function Attrs: noinline nounwind
> define void @f() #0 {
> entry:
> %call = call i32 @"\01CALCULATE"() ; Stepan: note \01 character.
> ret void
> }
> declare i32 @"\01CALCULATE"() #1
> ; some footer
>
> arm-linux-gnueabi emits:
>
> ; some header
> ; Function Attrs: nounwind
> define void @f() #0 {
> entry:
> %call = call i32 @CALCULATE() ; Stepan: no \01 character.
> ret void
> }
> declare i32 @CALCULATE() #1
> ;some footer
>
> But .S files looks fine. No \01 characters anywhere.
>
>
>
> About compiling avrlibc:
>
> >> Also avr-clang emits wrong sequense for .S files. So I'm using
> CCAS=avr-gcc.
> What do you mean with this? What is wrong?
>
> Directory:
> bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/__at90s1200
> bash:$ avr-clang -DHAVE_CONFIG_H -I.
> -I../../../../../avr-libc/avr/__lib/avr2/at90s1200 -I../../../..
> -I../../../../../avr-libc/__common
> -I../../../../../avr-libc/__include -I../../../../include
> -I../../../../../avr-libc/__common
> -I../../../../../avr-libc/__include -I../../../../include -x
> assembler-with-cpp -mmcu=at90s1200
> -DIOSYMFILE=\"iosym/at90s1200.__S\" -MT gcrt1.o -MD -MP -MF
> .deps/gcrt1.Tpo -c -o gcrt1.o ../../../../../avr-libc/crt1/__gcrt1.S
>
> tons of errors.
>
> I suppose thats because clang driver uses different tools for asm files.
>
> For the -### command avr-clang shows the next:
>
> "avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free"
> "-main-file-name" "gcrt1.S" "-mrelocation-model" "static"
> "-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases"
> "-target-linker-version" "2.22.90.20120924" "-coverage-file"
> "/tmp/gcrt1-fecbe5.s" "-resource-dir"
> "/media/stepan/workproj/llvm.__project/2-avr/builds/llvm.__debug-avr-arm-x86_64.build/__Debug+Asserts/bin/../lib/__clang/3.4"
> "-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps" "-MP" "-MT"
> "gcrt1.o" "-D" "HAVE_CONFIG_H" "-D"
> "IOSYMFILE=\"iosym/at90s1200.__S\"" "-I" "." "-I"
> "../../../../../avr-libc/avr/__lib/avr2/at90s1200" "-I"
> "../../../.." "-I" "../../../../../avr-libc/__common" "-I"
> "../../../../../avr-libc/__include" "-I" "../../../../include" "-I"
> "../../../../../avr-libc/__common" "-I"
> "../../../../../avr-libc/__include" "-I" "../../../../include"
> "-fno-dwarf-directory-asm" "-fdebug-compilation-dir"
> "/media/stepan/workproj/llvm.__project/2-avr/avr-libc/trunk/__build.opt/avr/lib/avr2/__at90s1200"
> "-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign"
> "-fobjc-runtime=gcc" "-fobjc-default-synthesize-__properties"
> "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops"
> "-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp"
> "../../../../../avr-libc/crt1/__gcrt1.S"
>
> "/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I"
> "../../../../../avr-libc/avr/__lib/avr2/at90s1200" "-I"
> "../../../.." "-I" "../../../../../avr-libc/__common" "-I"
> "../../../../../avr-libc/__include" "-I" "../../../../include" "-I"
> "../../../../../avr-libc/__common" "-I"
> "../../../../../avr-libc/__include" "-I" "../../../../include"
> "-mmcu=at90s1200" "-D" "IOSYMFILE=\"iosym/at90s1200.__S\"" "-MT"
> "gcrt1.o" "-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o" "gcrt1.o"
> "-x" "assembler" "/tmp/gcrt1-fecbe5.s"
>
> While avr-gcc uses next sequence:
>
> /usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I
> ../../../../../avr-libc/avr/__lib/avr2/at90s1200 -I ../../../.. -I
> ../../../../../avr-libc/common -I ../../../../../avr-libc/__include
> -I ../../../../include -I ../../../../../avr-libc/common -I
> ../../../../../avr-libc/__include -I ../../../../include -MD gcrt1.d
> -MF .deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D
> "IOSYMFILE=\"iosym/at90s1200.__S\""
> ../../../../../avr-libc/crt1/__gcrt1.S "-mmcu=at90s1200"
> -fno-directives-only -o /tmp/ccK7jMC3.s
> '-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"__' '-MT'
> 'gcrt1.o' '-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o' 'gcrt1.o'
>
> /usr/lib/gcc/avr/4.7.0/../../.__./avr/bin/as "-mmcu=at90s1200"
> -mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s
>
>
>
>
> 2) Since I compile clang as a cross compiler this is not a
> problem for
> me, all llvm binaries are prefixed with avr.
>
> >> Currently compilation stopped with unsupported movw
> instruction for
> avr2.
> Yes, this is going to be a problem. Try to modify the build
> scripts to
> compile everything for mmcu=avr5. We don't support any smaller
> devices.
>
>
> OK. Will do.
>
> -Stepan
>
>
>
>
> 2013/7/26 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
>
> Hello Borja,
>
> Thanks for fixes! Especially my stupid pieces of code in
> AVRAsmPrinter.cpp
>
>
> Back to your post at 01.07.2013:
>
> You wrote:
> [quote]
> Yes but the first goal now is to have inline asm feature
> complete xD
> Then we can move into other places of the library.
>
> Taking a look at the previous emails this is what needs
> still to be
> done:
> 1) Implement the missed optimization above for the memory
> constraint.
> Also see if you can come with further cases. Remember to
> add a test
> case.
> 2) Implement the stuff in the "C names used in assembler
> code" section
> of the avrlibc manual. You mentioned some issues here in a
> previous
> email.
> 3) Implement the a0, a1, etc... constraints.
> [/quote]
>
> 1. Done.
> 2. I checked it again. It works, though way of IR
> generation differs
> from ARM back-end for example.
> 3. Done.
>
> Now, I suppose, we have to work more with clang. But it is
> difficult
> since our changes are presented as patches.
>
> I had tried to compile avr-libc again. I had found clang
> bug (generic
> one: mistreating with builtins):
>
> http://llvm.org/bugs/show_bug.____cgi?id=16712
> <http://llvm.org/bugs/show_bug.__cgi?id=16712>
>
> <http://llvm.org/bugs/show___bug.cgi?id=16712
> <http://llvm.org/bugs/show_bug.cgi?id=16712>>
>
> Also avr-clang emits wrong sequense for .S files. So I'm using
> CCAS=avr-gcc.
>
> Steps for avr-libc compilation:
>
> 0. I'm working with avr-libc, svn r2403.
>
> 1. We also need to apply several changes for it (see the
> patch in
> attachment).
>
> 2. Currently you should rename "clang" with "avr-clang".
> "ln -s" doesn't
> works. 'avr-gcc' name was hard-coded in configure.ac
> <http://configure.ac>
> <http://configure.ac>, so I did the same
>
> with 'avr-clang'.
>
> 3. Run configure script as below:
> $AVR_LIBC_DIR/configure CC=$LLVM_BIN_DIR/avr-clang --build=
> --host=avr
> CCAS=avr-gcc
>
> A have also attached my config.log file.
>
> Currently compilation stopped with unsupported movw
> instruction for
> avr2.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Ok, you can commit the patch now.
>
>
> 2013/7/24 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...>>>>
>
> Borja Ferrer wrote:
>
> 1) I agree.
>
>
> 3) What happens when you use multibyte
> constraints with
> "e" or "b".
>
> Just had checked it. It works :-) Though I'll add
> test-cases for
> them too.
>
>
> 4) Hah ok, btw no need to check for i64?
>
> In one of our previous mails we decided to
> restrict i64
> usage, since
> avr-gcc doesn't support it properly.
>
> -Stepan
>
>
>
> 2013/7/24 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...>>>>>
>
> Hi Borja,
>
>
> > 1) You implemented the "aN" constraint
> by also
> allowing
> b,c,d
> > constraints. I'm not sure if gcc
> implements
> this, my
> guess is
> that only
> > "a" is needed. Please check to see
> what gcc
> does here.
>
> For b,c,d avr-gcc acts like it meet %a. I
> think
> its wrong and
> untested behaviour, so I just restricted
> usage to
> single
> 'a' character.
>
>
> > 2) Make getAlternativeRegName return a
> char
> instead of a
> string
> since we
> > only need to return one letter.
>
> Done
>
>
> > 3) Related to the changes in
> AVRISelLowering.cpp, do we
> need to care
> > about more register constraints apart
> of the
> ones you
> already
> covered?
>
> What you mean? I think all constraints
> are covered
> now. If
> no, we
> can find out it during compilation (avr-libc,
> arduino, etc).
>
>
> > 4) Now that wider types have been covered,
> please check
> if the
> assert I
> > commented out in AVRISelLowering.cpp
> in the
> inline asm
> code can be
> > removed or what.
>
> I replaced this assertion with error message.
> Suppose its
> better
> than killing the compiler :-)
>
> New patch is attached.
>
> -Stepan.
>
>
> Borja Ferrer wrote:
>
> Hello Stepan,
> The patch looks good, but I have some
> questions/comments:
>
> 1) You implemented the "aN"
> constraint by also
> allowing
> b,c,d
> constraints. I'm not sure if gcc
> implements
> this, my
> guess is
> that only
> "a" is needed. Please check to see
> what gcc
> does here.
> 2) Make getAlternativeRegName return
> a char
> instead of
> a string
> since we
> only need to return one letter.
> 3) Related to the changes in
> AVRISelLowering.cpp, do we
> need to care
> about more register constraints apart
> of the
> ones you
> already
> covered?
> 4) Now that wider types have been
> covered,
> please check
> if the
> assert I
> commented out in AVRISelLowering.cpp
> in the
> inline asm
> code can be
> removed or what.
>
>
>
> 2013/7/24 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...>>>>
> <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... <mailto:stp...@na...>>>>>>
>
>
> Hello Borja,
> Here is the new patch for multibyte
> reference.
> Please look
> at new
> tests to see what was
> implemented exactly.
> To fix issue I described in previous
> letter I've
> added new reg
> classes that contains pairs of 8 bit
> registers:
> If we pass i32 parameter that
> should be
> split onto
> four 8
> bit regs,
> we set i16 register class first,
> then it
> would be
> replaced
> with 8
> bit registers if needed.
> Currently I see
> it is the
> only
> solution
> that doesn't touch vmcore.
>
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>
> Hello Borja,
> Great. I have found out next
> inline-asm issue.
> When you pass i32 bit type,
> it could
> be split
> onto two
> registers
> only,
> no matter which register
> class you
> set for it.
> This
> behaviour is
> implemented in
> SelectionDAGBuilder::__________visitInlineAsm.
>
>
> I think I'll
>
> implement simplest version of
> ExpandInlineAsm
> today,
> that will fix
> operand types properly.
>
> -Stepan
>
> Borja Ferrer wrote:
>
> I've been adding fixes
> to pass a
> ton of
> regression
> in the
> Generic folder.
> Currently there are two
> tests
> that fail with a
> "cannot select
> build_pair" related to
> adding
> 16bit reg
> classes in the
> inline asm code.
> The rest of failing
> tests are
> related with not
> being able to
> run llc
> with -O0. There's a serious
> codegen bug
> that i spotted
> yesterday while
> doing the fixes that I
> need to
> work on.
>
>
> 2013/7/22 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...>>__>__>
>
> <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...
> <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...>
> <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...
> <mailto:bor...@gm...>
> <mailto:bor...@gm...
> <mailto:bor...@gm...>>__>__>__>__>__>
>
>
>
> Hello Stepan,
>
> 3) Yes, it's the
> second
> case. It's
> explained in
> http://www.nongnu.org/avr-__________libc/user-manual/inline___asm.________html
> <http://www.nongnu.org/avr-________libc/user-manual/inline_asm.________html>
>
> <http://www.nongnu.org/avr-________libc/user-manual/inline___asm.______html
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>>
>
>
>
> <http://www.nongnu.org/avr-________libc/user-manual/inline___asm.______html
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>>>
>
>
>
> <http://www.nongnu.org/avr-________libc/user-manual/inline___asm.______html
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>>
>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>>>
>
>
>
>
>
>
> <http://www.nongnu.org/avr-________libc/user-manual/inline___asm.______html
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>>
>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>>
>
>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>
>
>
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>
>
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html
> <http://www.nongnu.org/avr-libc/user-manual/inline_asm.html>>>>>
> but in case there
> are any
> doubts
> basically it
> works
> the same way as
> multibyte constraints
> except that
> when you see an
> "aN", where N is a
> number, you should
> print
> the alternative
> regname. Of
> course this
> should only work
> for X Y
> and Z, not
> sure how gcc
> complains when you
> use another
> register, or
> maybe it
> ignores it and
> prints the normal
> register name.
>
>
>
>
>
>
>
>
> ------------------------------__________----------------------__--__--__--__--__--------------__----
>
>
>
> 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
>
>
> <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://sourcef______orge.net>
> <http://sourcef____orge.net>
>
> <http://sourcef__orge.net>
> <http://sourceforge.net>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>>.__>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net>
>
> <http://sourceforge.net>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.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>>
>
>
> <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
>
>
> <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
>
>
>
>
> <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>>>>>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-26 11:58:21
|
Ok I will take a look at that 01 character to see from where it's coming
from.
About the other issue, it's weird, i've managed to build a huge c file with
avr-clang with no errors. Since i have avr-as and the rest of avr binutils
in my PATH, avr-clang calls them automatically to assemble and link the
program. The only thing i MUST do is pass mmcu=avr5 otherwise i get all
those movw errors in the assembler. Remember to configure LLVM with the
--target, --host, etc options to build it as a cross compiler.
I'm also seeing a lot of references to avr2 and the at90s120 inside those
cmd lines, I dont know if this makes any difference but again, we cant
compile for those mcus now.
2013/7/26 Stepan Dyatkovskiy <stp...@na...>
> Borja Ferrer wrote:
>
>> Hello Stepan,
>>
>> No problem with those fixes :)
>>
>>
> 2) It's interesting we get different IR, can you explain more what is
>> going on here? This is the last bit of inline asm support, the sooner we
>> fix it the better so we can move on to more interesting things.
>>
>
> For next example:
>
> int a,b;
> extern long Calc(void) asm ("CALCULATE");
> void f() { Calc(); }
>
> avr-clang emits:
>
> ; some header
> ; Function Attrs: noinline nounwind
> define void @f() #0 {
> entry:
> %call = call i32 @"\01CALCULATE"() ; Stepan: note \01 character.
> ret void
> }
> declare i32 @"\01CALCULATE"() #1
> ; some footer
>
> arm-linux-gnueabi emits:
>
> ; some header
> ; Function Attrs: nounwind
> define void @f() #0 {
> entry:
> %call = call i32 @CALCULATE() ; Stepan: no \01 character.
> ret void
> }
> declare i32 @CALCULATE() #1
> ;some footer
>
> But .S files looks fine. No \01 characters anywhere.
>
>
>
>> About compiling avrlibc:
>>
>> >> Also avr-clang emits wrong sequense for .S files. So I'm using
>> CCAS=avr-gcc.
>> What do you mean with this? What is wrong?
>>
> Directory:
> bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/**at90s1200
> bash:$ avr-clang -DHAVE_CONFIG_H -I. -I../../../../../avr-libc/avr/**lib/avr2/at90s1200
> -I../../../.. -I../../../../../avr-libc/**common
> -I../../../../../avr-libc/**include -I../../../../include
> -I../../../../../avr-libc/**common -I../../../../../avr-libc/**include
> -I../../../../include -x assembler-with-cpp -mmcu=at90s1200
> -DIOSYMFILE=\"iosym/at90s1200.**S\" -MT gcrt1.o -MD -MP -MF
> .deps/gcrt1.Tpo -c -o gcrt1.o ../../../../../avr-libc/crt1/**gcrt1.S
>
> tons of errors.
>
> I suppose thats because clang driver uses different tools for asm files.
>
> For the -### command avr-clang shows the next:
>
> "avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free" "-main-file-name"
> "gcrt1.S" "-mrelocation-model" "static" "-mdisable-fp-elim" "-fmath-errno"
> "-mconstructor-aliases" "-target-linker-version" "2.22.90.20120924"
> "-coverage-file" "/tmp/gcrt1-fecbe5.s" "-resource-dir"
> "/media/stepan/workproj/llvm.**project/2-avr/builds/llvm.**
> debug-avr-arm-x86_64.build/**Debug+Asserts/bin/../lib/**clang/3.4"
> "-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps" "-MP" "-MT"
> "gcrt1.o" "-D" "HAVE_CONFIG_H" "-D" "IOSYMFILE=\"iosym/at90s1200.**S\""
> "-I" "." "-I" "../../../../../avr-libc/avr/**lib/avr2/at90s1200" "-I"
> "../../../.." "-I" "../../../../../avr-libc/**common" "-I"
> "../../../../../avr-libc/**include" "-I" "../../../../include" "-I"
> "../../../../../avr-libc/**common" "-I" "../../../../../avr-libc/**include"
> "-I" "../../../../include" "-fno-dwarf-directory-asm"
> "-fdebug-compilation-dir" "/media/stepan/workproj/llvm.**
> project/2-avr/avr-libc/trunk/**build.opt/avr/lib/avr2/**at90s1200"
> "-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign"
> "-fobjc-runtime=gcc" "-fobjc-default-synthesize-**properties"
> "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" "-o"
> "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp"
> "../../../../../avr-libc/crt1/**gcrt1.S"
>
> "/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I"
> "../../../../../avr-libc/avr/**lib/avr2/at90s1200" "-I" "../../../.."
> "-I" "../../../../../avr-libc/**common" "-I" "../../../../../avr-libc/**include"
> "-I" "../../../../include" "-I" "../../../../../avr-libc/**common" "-I"
> "../../../../../avr-libc/**include" "-I" "../../../../include"
> "-mmcu=at90s1200" "-D" "IOSYMFILE=\"iosym/at90s1200.**S\"" "-MT"
> "gcrt1.o" "-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o" "gcrt1.o" "-x"
> "assembler" "/tmp/gcrt1-fecbe5.s"
>
> While avr-gcc uses next sequence:
>
> /usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I
> ../../../../../avr-libc/avr/**lib/avr2/at90s1200 -I ../../../.. -I
> ../../../../../avr-libc/common -I ../../../../../avr-libc/**include -I
> ../../../../include -I ../../../../../avr-libc/common -I
> ../../../../../avr-libc/**include -I ../../../../include -MD gcrt1.d -MF
> .deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D
> "IOSYMFILE=\"iosym/at90s1200.**S\"" ../../../../../avr-libc/crt1/**gcrt1.S
> "-mmcu=at90s1200" -fno-directives-only -o /tmp/ccK7jMC3.s
> '-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"**' '-MT' 'gcrt1.o'
> '-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o' 'gcrt1.o'
>
> /usr/lib/gcc/avr/4.7.0/../../.**./avr/bin/as "-mmcu=at90s1200"
> -mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s
>
>
>
>
>> 2) Since I compile clang as a cross compiler this is not a problem for
>> me, all llvm binaries are prefixed with avr.
>>
>> >> Currently compilation stopped with unsupported movw instruction for
>> avr2.
>> Yes, this is going to be a problem. Try to modify the build scripts to
>> compile everything for mmcu=avr5. We don't support any smaller devices.
>>
>
> OK. Will do.
>
> -Stepan
>
>
>>
>>
>> 2013/7/26 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...
>> >>
>>
>>
>> Hello Borja,
>>
>> Thanks for fixes! Especially my stupid pieces of code in
>> AVRAsmPrinter.cpp
>>
>>
>> Back to your post at 01.07.2013:
>>
>> You wrote:
>> [quote]
>> Yes but the first goal now is to have inline asm feature complete xD
>> Then we can move into other places of the library.
>>
>> Taking a look at the previous emails this is what needs still to be
>> done:
>> 1) Implement the missed optimization above for the memory constraint.
>> Also see if you can come with further cases. Remember to add a test
>> case.
>> 2) Implement the stuff in the "C names used in assembler code" section
>> of the avrlibc manual. You mentioned some issues here in a previous
>> email.
>> 3) Implement the a0, a1, etc... constraints.
>> [/quote]
>>
>> 1. Done.
>> 2. I checked it again. It works, though way of IR generation differs
>> from ARM back-end for example.
>> 3. Done.
>>
>> Now, I suppose, we have to work more with clang. But it is difficult
>> since our changes are presented as patches.
>>
>> I had tried to compile avr-libc again. I had found clang bug (generic
>> one: mistreating with builtins):
>>
>> http://llvm.org/bugs/show_bug.**__cgi?id=16712<http://llvm.org/bugs/show_bug.__cgi?id=16712>
>>
>> <http://llvm.org/bugs/show_**bug.cgi?id=16712<http://llvm.org/bugs/show_bug.cgi?id=16712>
>> >
>>
>> Also avr-clang emits wrong sequense for .S files. So I'm using
>> CCAS=avr-gcc.
>>
>> Steps for avr-libc compilation:
>>
>> 0. I'm working with avr-libc, svn r2403.
>>
>> 1. We also need to apply several changes for it (see the patch in
>> attachment).
>>
>> 2. Currently you should rename "clang" with "avr-clang". "ln -s"
>> doesn't
>> works. 'avr-gcc' name was hard-coded in configure.ac
>> <http://configure.ac>, so I did the same
>>
>> with 'avr-clang'.
>>
>> 3. Run configure script as below:
>> $AVR_LIBC_DIR/configure CC=$LLVM_BIN_DIR/avr-clang --build= --host=avr
>> CCAS=avr-gcc
>>
>> A have also attached my config.log file.
>>
>> Currently compilation stopped with unsupported movw instruction for
>> avr2.
>>
>> -Stepan.
>>
>> Borja Ferrer wrote:
>>
>> Ok, you can commit the patch now.
>>
>>
>> 2013/7/24 Stepan Dyatkovskiy <stp...@na...
>> <mailto:stp...@na...> <mailto:stp...@na...
>>
>> <mailto:stp...@na...>>>
>>
>> Borja Ferrer wrote:
>>
>> 1) I agree.
>>
>>
>> 3) What happens when you use multibyte constraints with
>> "e" or "b".
>>
>> Just had checked it. It works :-) Though I'll add
>> test-cases for
>> them too.
>>
>>
>> 4) Hah ok, btw no need to check for i64?
>>
>> In one of our previous mails we decided to restrict i64
>> usage, since
>> avr-gcc doesn't support it properly.
>>
>> -Stepan
>>
>>
>>
>> 2013/7/24 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...>>>>
>>
>> Hi Borja,
>>
>>
>> > 1) You implemented the "aN" constraint by also
>> allowing
>> b,c,d
>> > constraints. I'm not sure if gcc implements
>> this, my
>> guess is
>> that only
>> > "a" is needed. Please check to see what gcc
>> does here.
>>
>> For b,c,d avr-gcc acts like it meet %a. I think
>> its wrong and
>> untested behaviour, so I just restricted usage to
>> single
>> 'a' character.
>>
>>
>> > 2) Make getAlternativeRegName return a char
>> instead of a
>> string
>> since we
>> > only need to return one letter.
>>
>> Done
>>
>>
>> > 3) Related to the changes in
>> AVRISelLowering.cpp, do we
>> need to care
>> > about more register constraints apart of the
>> ones you
>> already
>> covered?
>>
>> What you mean? I think all constraints are covered
>> now. If
>> no, we
>> can find out it during compilation (avr-libc,
>> arduino, etc).
>>
>>
>> > 4) Now that wider types have been covered,
>> please check
>> if the
>> assert I
>> > commented out in AVRISelLowering.cpp in the
>> inline asm
>> code can be
>> > removed or what.
>>
>> I replaced this assertion with error message.
>> Suppose its
>> better
>> than killing the compiler :-)
>>
>> New patch is attached.
>>
>> -Stepan.
>>
>>
>> Borja Ferrer wrote:
>>
>> Hello Stepan,
>> The patch looks good, but I have some
>> questions/comments:
>>
>> 1) You implemented the "aN" constraint by also
>> allowing
>> b,c,d
>> constraints. I'm not sure if gcc implements
>> this, my
>> guess is
>> that only
>> "a" is needed. Please check to see what gcc
>> does here.
>> 2) Make getAlternativeRegName return a char
>> instead of
>> a string
>> since we
>> only need to return one letter.
>> 3) Related to the changes in
>> AVRISelLowering.cpp, do we
>> need to care
>> about more register constraints apart of the
>> ones you
>> already
>> covered?
>> 4) Now that wider types have been covered,
>> please check
>> if the
>> assert I
>> commented out in AVRISelLowering.cpp in the
>> inline asm
>> code can be
>> removed or what.
>>
>>
>>
>> 2013/7/24 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...>>>>>
>>
>>
>> Hello Borja,
>> Here is the new patch for multibyte
>> reference.
>> Please look
>> at new
>> tests to see what was implemented exactly.
>> To fix issue I described in previous
>> letter I've
>> added new reg
>> classes that contains pairs of 8 bit
>> registers:
>> If we pass i32 parameter that should be
>> split onto
>> four 8
>> bit regs,
>> we set i16 register class first, then it
>> would be
>> replaced
>> with 8
>> bit registers if needed. Currently I see
>> it is the
>> only
>> solution
>> that doesn't touch vmcore.
>>
>> -Stepan.
>>
>> Stepan Dyatkovskiy wrote:
>>
>> Hello Borja,
>> Great. I have found out next
>> inline-asm issue.
>> When you pass i32 bit type, it could
>> be split
>> onto two
>> registers
>> only,
>> no matter which register class you
>> set for it.
>> This
>> behaviour is
>> implemented in
>> SelectionDAGBuilder::________**visitInlineAsm.
>>
>>
>> I think I'll
>>
>> implement simplest version of
>> ExpandInlineAsm
>> today,
>> that will fix
>> operand types properly.
>>
>> -Stepan
>>
>> Borja Ferrer wrote:
>>
>> I've been adding fixes to pass a
>> ton of
>> regression
>> in the
>> Generic folder.
>> Currently there are two tests
>> that fail with a
>> "cannot select
>> build_pair" related to adding
>> 16bit reg
>> classes in the
>> inline asm code.
>> The rest of failing tests are
>> related with not
>> being able to
>> run llc
>> with -O0. There's a serious
>> codegen bug
>> that i spotted
>> yesterday while
>> doing the fixes that I need to
>> work on.
>>
>>
>> 2013/7/22 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...>**>__>__>
>> <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...
>> <mailto:bor...@gm...>**>__>__>__>__>
>>
>>
>>
>> Hello Stepan,
>>
>> 3) Yes, it's the second
>> case. It's
>> explained in
>> http://www.nongnu.org/avr-____**____libc/user-manual/inline_**
>> asm.________html<http://www.nongnu.org/avr-________libc/user-manual/inline_asm.________html>
>> <http://www.nongnu.org/avr-___**___libc/user-manual/inline_**
>> asm.______html<http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>
>> >
>>
>>
>> <http://www.nongnu.org/avr-___**___libc/user-manual/inline_**
>> asm.______html<http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>
>> <http://www.nongnu.org/avr-___**_libc/user-manual/inline_asm._**
>> ___html<http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>> >>
>>
>>
>> <http://www.nongnu.org/avr-___**___libc/user-manual/inline_**
>> asm.______html<http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>
>> <http://www.nongnu.org/avr-___**_libc/user-manual/inline_asm._**
>> ___html<http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>> >
>>
>> <http://www.nongnu.org/avr-___**_libc/user-manual/inline_asm._**
>> ___html<http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>> <http://www.nongnu.org/avr-__**libc/user-manual/inline_asm.__**
>> html <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>>>
>>
>>
>>
>>
>>
>> <http://www.nongnu.org/avr-___**___libc/user-manual/inline_**
>> asm.______html<http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>
>> <http://www.nongnu.org/avr-___**_libc/user-manual/inline_asm._**
>> ___html<http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>> >
>>
>> <http://www.nongnu.org/avr-___**_libc/user-manual/inline_asm._**
>> ___html<http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>> <http://www.nongnu.org/avr-__**libc/user-manual/inline_asm.__**
>> html <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>>
>>
>>
>> <http://www.nongnu.org/avr-___**_libc/user-manual/inline_asm._**
>> ___html<http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>> <http://www.nongnu.org/avr-__**libc/user-manual/inline_asm.__**
>> html <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>
>>
>> <http://www.nongnu.org/avr-__**libc/user-manual/inline_asm.__**
>> html <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>
>> <http://www.nongnu.org/avr-**libc/user-manual/inline_asm.**html<http://www.nongnu.org/avr-libc/user-manual/inline_asm.html>
>> >>>>
>> but in case there are any
>> doubts
>> basically it
>> works
>> the same way as
>> multibyte constraints
>> except that
>> when you see an
>> "aN", where N is a
>> number, you should print
>> the alternative
>> regname. Of
>> course this
>> should only work for X Y
>> and Z, not
>> sure how gcc
>> complains when you
>> use another register, or
>> maybe it
>> ignores it and
>> prints the normal
>> register name.
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------**________----------------------**
>> --__--__--__--__--------------**----
>>
>>
>>
>> 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
>>
>> <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://sourcef______orge.net>
>> <http://sourcef____orge.net>
>>
>> <http://sourcef__orge.net>
>> <http://sourceforge.net>
>> <mailto:avr-llvm-devel@lists
>> <mailto:avr-llvm-devel@lists>.
>> <mailto:avr-llvm-devel@lists
>> <mailto:avr-llvm-devel@lists>.**>______sourceforge.net
>> <http://sourceforge.net>
>>
>> <http://sourceforge.net>
>> <mailto:avr-llvm-devel@lists.
>> <mailto:avr-llvm-devel@lists.>**____sourceforge.net
>> <http://sourceforge.net>
>> <mailto:avr-llvm-devel@lists._**_sourceforge.net
>> <mailto: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>
>> <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<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 <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
>> <https://lists.sourceforge.**net/lists/listinfo/avr-llvm-**devel<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>
>> >>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-26 11:42:51
|
Borja Ferrer wrote:
> Hello Stepan,
> No problem with those fixes :)
>
> 2) It's interesting we get different IR, can you explain more what is
> going on here? This is the last bit of inline asm support, the sooner we
> fix it the better so we can move on to more interesting things.
For next example:
int a,b;
extern long Calc(void) asm ("CALCULATE");
void f() { Calc(); }
avr-clang emits:
; some header
; Function Attrs: noinline nounwind
define void @f() #0 {
entry:
%call = call i32 @"\01CALCULATE"() ; Stepan: note \01 character.
ret void
}
declare i32 @"\01CALCULATE"() #1
; some footer
arm-linux-gnueabi emits:
; some header
; Function Attrs: nounwind
define void @f() #0 {
entry:
%call = call i32 @CALCULATE() ; Stepan: no \01 character.
ret void
}
declare i32 @CALCULATE() #1
;some footer
But .S files looks fine. No \01 characters anywhere.
>
> About compiling avrlibc:
>
> >> Also avr-clang emits wrong sequense for .S files. So I'm using
> CCAS=avr-gcc.
> What do you mean with this? What is wrong?
Directory:
bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/at90s1200
bash:$ avr-clang -DHAVE_CONFIG_H -I.
-I../../../../../avr-libc/avr/lib/avr2/at90s1200 -I../../../..
-I../../../../../avr-libc/common -I../../../../../avr-libc/include
-I../../../../include -I../../../../../avr-libc/common
-I../../../../../avr-libc/include -I../../../../include -x
assembler-with-cpp -mmcu=at90s1200 -DIOSYMFILE=\"iosym/at90s1200.S\"
-MT gcrt1.o -MD -MP -MF .deps/gcrt1.Tpo -c -o gcrt1.o
../../../../../avr-libc/crt1/gcrt1.S
tons of errors.
I suppose thats because clang driver uses different tools for asm files.
For the -### command avr-clang shows the next:
"avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free"
"-main-file-name" "gcrt1.S" "-mrelocation-model" "static"
"-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases"
"-target-linker-version" "2.22.90.20120924" "-coverage-file"
"/tmp/gcrt1-fecbe5.s" "-resource-dir"
"/media/stepan/workproj/llvm.project/2-avr/builds/llvm.debug-avr-arm-x86_64.build/Debug+Asserts/bin/../lib/clang/3.4"
"-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps" "-MP" "-MT"
"gcrt1.o" "-D" "HAVE_CONFIG_H" "-D" "IOSYMFILE=\"iosym/at90s1200.S\""
"-I" "." "-I" "../../../../../avr-libc/avr/lib/avr2/at90s1200" "-I"
"../../../.." "-I" "../../../../../avr-libc/common" "-I"
"../../../../../avr-libc/include" "-I" "../../../../include" "-I"
"../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include"
"-I" "../../../../include" "-fno-dwarf-directory-asm"
"-fdebug-compilation-dir"
"/media/stepan/workproj/llvm.project/2-avr/avr-libc/trunk/build.opt/avr/lib/avr2/at90s1200"
"-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign"
"-fobjc-runtime=gcc" "-fobjc-default-synthesize-properties"
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops"
"-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp"
"../../../../../avr-libc/crt1/gcrt1.S"
"/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I"
"../../../../../avr-libc/avr/lib/avr2/at90s1200" "-I" "../../../.." "-I"
"../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include"
"-I" "../../../../include" "-I" "../../../../../avr-libc/common" "-I"
"../../../../../avr-libc/include" "-I" "../../../../include"
"-mmcu=at90s1200" "-D" "IOSYMFILE=\"iosym/at90s1200.S\"" "-MT" "gcrt1.o"
"-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o" "gcrt1.o" "-x" "assembler"
"/tmp/gcrt1-fecbe5.s"
While avr-gcc uses next sequence:
/usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I
../../../../../avr-libc/avr/lib/avr2/at90s1200 -I ../../../.. -I
../../../../../avr-libc/common -I ../../../../../avr-libc/include -I
../../../../include -I ../../../../../avr-libc/common -I
../../../../../avr-libc/include -I ../../../../include -MD gcrt1.d -MF
.deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D
"IOSYMFILE=\"iosym/at90s1200.S\"" ../../../../../avr-libc/crt1/gcrt1.S
"-mmcu=at90s1200" -fno-directives-only -o /tmp/ccK7jMC3.s
'-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"' '-MT' 'gcrt1.o'
'-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o' 'gcrt1.o'
/usr/lib/gcc/avr/4.7.0/../../../avr/bin/as "-mmcu=at90s1200"
-mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s
>
> 2) Since I compile clang as a cross compiler this is not a problem for
> me, all llvm binaries are prefixed with avr.
>
> >> Currently compilation stopped with unsupported movw instruction for
> avr2.
> Yes, this is going to be a problem. Try to modify the build scripts to
> compile everything for mmcu=avr5. We don't support any smaller devices.
OK. Will do.
-Stepan
>
>
>
> 2013/7/26 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>>
>
> Hello Borja,
>
> Thanks for fixes! Especially my stupid pieces of code in
> AVRAsmPrinter.cpp
>
>
> Back to your post at 01.07.2013:
>
> You wrote:
> [quote]
> Yes but the first goal now is to have inline asm feature complete xD
> Then we can move into other places of the library.
>
> Taking a look at the previous emails this is what needs still to be
> done:
> 1) Implement the missed optimization above for the memory constraint.
> Also see if you can come with further cases. Remember to add a test
> case.
> 2) Implement the stuff in the "C names used in assembler code" section
> of the avrlibc manual. You mentioned some issues here in a previous
> email.
> 3) Implement the a0, a1, etc... constraints.
> [/quote]
>
> 1. Done.
> 2. I checked it again. It works, though way of IR generation differs
> from ARM back-end for example.
> 3. Done.
>
> Now, I suppose, we have to work more with clang. But it is difficult
> since our changes are presented as patches.
>
> I had tried to compile avr-libc again. I had found clang bug (generic
> one: mistreating with builtins):
>
> http://llvm.org/bugs/show_bug.__cgi?id=16712
> <http://llvm.org/bugs/show_bug.cgi?id=16712>
>
> Also avr-clang emits wrong sequense for .S files. So I'm using
> CCAS=avr-gcc.
>
> Steps for avr-libc compilation:
>
> 0. I'm working with avr-libc, svn r2403.
>
> 1. We also need to apply several changes for it (see the patch in
> attachment).
>
> 2. Currently you should rename "clang" with "avr-clang". "ln -s" doesn't
> works. 'avr-gcc' name was hard-coded in configure.ac
> <http://configure.ac>, so I did the same
> with 'avr-clang'.
>
> 3. Run configure script as below:
> $AVR_LIBC_DIR/configure CC=$LLVM_BIN_DIR/avr-clang --build= --host=avr
> CCAS=avr-gcc
>
> A have also attached my config.log file.
>
> Currently compilation stopped with unsupported movw instruction for
> avr2.
>
> -Stepan.
>
> Borja Ferrer wrote:
>
> Ok, you can commit the patch now.
>
>
> 2013/7/24 Stepan Dyatkovskiy <stp...@na...
> <mailto:stp...@na...> <mailto:stp...@na...
> <mailto:stp...@na...>>>
>
> Borja Ferrer wrote:
>
> 1) I agree.
>
>
> 3) What happens when you use multibyte constraints with
> "e" or "b".
>
> Just had checked it. It works :-) Though I'll add
> test-cases for
> them too.
>
>
> 4) Hah ok, btw no need to check for i64?
>
> In one of our previous mails we decided to restrict i64
> usage, since
> avr-gcc doesn't support it properly.
>
> -Stepan
>
>
>
> 2013/7/24 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...>>>>
>
> Hi Borja,
>
>
> > 1) You implemented the "aN" constraint by also
> allowing
> b,c,d
> > constraints. I'm not sure if gcc implements
> this, my
> guess is
> that only
> > "a" is needed. Please check to see what gcc
> does here.
>
> For b,c,d avr-gcc acts like it meet %a. I think
> its wrong and
> untested behaviour, so I just restricted usage to
> single
> 'a' character.
>
>
> > 2) Make getAlternativeRegName return a char
> instead of a
> string
> since we
> > only need to return one letter.
>
> Done
>
>
> > 3) Related to the changes in
> AVRISelLowering.cpp, do we
> need to care
> > about more register constraints apart of the
> ones you
> already
> covered?
>
> What you mean? I think all constraints are covered
> now. If
> no, we
> can find out it during compilation (avr-libc,
> arduino, etc).
>
>
> > 4) Now that wider types have been covered,
> please check
> if the
> assert I
> > commented out in AVRISelLowering.cpp in the
> inline asm
> code can be
> > removed or what.
>
> I replaced this assertion with error message.
> Suppose its
> better
> than killing the compiler :-)
>
> New patch is attached.
>
> -Stepan.
>
>
> Borja Ferrer wrote:
>
> Hello Stepan,
> The patch looks good, but I have some
> questions/comments:
>
> 1) You implemented the "aN" constraint by also
> allowing
> b,c,d
> constraints. I'm not sure if gcc implements
> this, my
> guess is
> that only
> "a" is needed. Please check to see what gcc
> does here.
> 2) Make getAlternativeRegName return a char
> instead of
> a string
> since we
> only need to return one letter.
> 3) Related to the changes in
> AVRISelLowering.cpp, do we
> need to care
> about more register constraints apart of the
> ones you
> already
> covered?
> 4) Now that wider types have been covered,
> please check
> if the
> assert I
> commented out in AVRISelLowering.cpp in the
> inline asm
> code can be
> removed or what.
>
>
>
> 2013/7/24 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...>>>>>
>
>
> Hello Borja,
> Here is the new patch for multibyte
> reference.
> Please look
> at new
> tests to see what was implemented exactly.
> To fix issue I described in previous
> letter I've
> added new reg
> classes that contains pairs of 8 bit
> registers:
> If we pass i32 parameter that should be
> split onto
> four 8
> bit regs,
> we set i16 register class first, then it
> would be
> replaced
> with 8
> bit registers if needed. Currently I see
> it is the
> only
> solution
> that doesn't touch vmcore.
>
> -Stepan.
>
> Stepan Dyatkovskiy wrote:
>
> Hello Borja,
> Great. I have found out next
> inline-asm issue.
> When you pass i32 bit type, it could
> be split
> onto two
> registers
> only,
> no matter which register class you
> set for it.
> This
> behaviour is
> implemented in
> SelectionDAGBuilder::________visitInlineAsm.
>
> I think I'll
>
> implement simplest version of
> ExpandInlineAsm
> today,
> that will fix
> operand types properly.
>
> -Stepan
>
> Borja Ferrer wrote:
>
> I've been adding fixes to pass a
> ton of
> regression
> in the
> Generic folder.
> Currently there are two tests
> that fail with a
> "cannot select
> build_pair" related to adding
> 16bit reg
> classes in the
> inline asm code.
> The rest of failing tests are
> related with not
> being able to
> run llc
> with -O0. There's a serious
> codegen bug
> that i spotted
> yesterday while
> doing the fixes that I need to
> work on.
>
>
> 2013/7/22 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...>>__>__>
> <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...
> <mailto:bor...@gm...>>__>__>__>__>
>
>
> Hello Stepan,
>
> 3) Yes, it's the second
> case. It's
> explained in
> http://www.nongnu.org/avr-________libc/user-manual/inline_asm.________html
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>>
>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>>
>
>
>
>
>
> <http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html>
>
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>>
>
>
> <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>
>
> <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html
> <http://www.nongnu.org/avr-libc/user-manual/inline_asm.html>>>>
> but in case there are any
> doubts
> basically it
> works
> the same way as
> multibyte constraints
> except that
> when you see an
> "aN", where N is a
> number, you should print
> the alternative
> regname. Of
> course this
> should only work for X Y
> and Z, not
> sure how gcc
> complains when you
> use another register, or
> maybe it
> ignores it and
> prints the normal
> register name.
>
>
>
>
>
>
>
> ------------------------------________------------------------__--__--__--__------------------
>
>
> 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
>
> <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://sourcef____orge.net>
> <http://sourcef__orge.net>
> <http://sourceforge.net>
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.
> <mailto:avr-llvm-devel@lists
> <mailto:avr-llvm-devel@lists>.>______sourceforge.net
> <http://sourceforge.net>
> <http://sourceforge.net>
> <mailto:avr-llvm-devel@lists.
> <mailto:avr-llvm-devel@lists.>____sourceforge.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>>
>
> <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
>
>
> <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>>>>
>
>
>
>
>
>
>
>
>
>
|
14 messages has been excluded from this view by a project administrator.
