Menu
▾
▴
Re: [avr-llvm-devel] Supporting targets without "call" (ATtiny13)
|
From: Borja F. <bor...@gm...> - 2013-09-27 11:21:05
|
Hello,
Currently our avr backend only supports the atmega644 mcu. Your patch about
rcall works for that cpu, but bear in mind that other unsupported
instructions will get generated like mul and friends.
Yes, rcall is shorter and faster to execute but at this stage very few
optimizations are implemented in favour of getting a fully functional
compiler. Indeed rcall is not always safe to use in larger targets, that
should be resolved by the linker when symbols get resolved.
2013/9/27 Matthijs Kooijman <mat...@st...>
> Hi folks,
>
> I just tried avr-llvm for the first time and after I finally properly
> followed the official instructions (I first didn't see that you also
> need a patched clang), I got things to run and compile. I did need a
> tiny patch to make it compile (PCSymbol was removed in llvm r191362):
>
> Index: AVR/MCTargetDesc/AVRMCAsmInfo.cpp
> ===================================================================
> --- AVR/MCTargetDesc/AVRMCAsmInfo.cpp (revision 293)
> +++ AVR/MCTargetDesc/AVRMCAsmInfo.cpp (working copy)
> @@ -22,7 +22,6 @@
> {
> PointerSize = CalleeSaveStackSlotSize = 2;
>
> - PCSymbol = ".";
> CommentString = ";";
> PrivateGlobalPrefix = ".L";
>
>
>
> Running clang for my ATtiny13, I did get another error:
>
> $ clang -Os -I/usr/lib/avr/include -D__AVR_ATtiny13__ -target avr
> -Wno-attributes backpack.c
> /tmp/backpack-7ccd60.s: Assembler messages:
> /tmp/backpack-7ccd60.s:376: Error: illegal opcode call for mcu avr2
> /tmp/backpack-7ccd60.s:462: Error: illegal opcode call for mcu avr2
> /tmp/backpack-7ccd60.s:503: Error: illegal opcode call for mcu avr2
> /tmp/backpack-7ccd60.s:505: Error: illegal opcode call for mcu avr2
> clang-3.4: error: assembler (via gcc) command failed with exit
> code 1 (use -v to see invocation)
>
> I'm not entirely sure if I'm specifying my target CPU correctly, but the
> complaint from the assembler looks valid (the tiny13 really doesn't have
> a call instruction, only icall and rcall).
>
> Looking in the code, I don't see anything for emitting rcall, so I guess
> this is just not implemented yet. If I simply replace the call
> instruction with rcall in the code, my program compiles succesfully.
>
> Index: AVRInstrInfo.td
> ===================================================================
> --- AVRInstrInfo.td (revision 293)
> +++ AVRInstrInfo.td (working copy)
> @@ -812,7 +812,7 @@
> //:TODO: the imm field can be either 16 or 22 bits in devices with
> more
> // than 64k of ROM, fix it once we support the largests devices.
> (ins i16imm:$dst),
> - "call\t$dst",
> + "rcall\t$dst",
> [(AVRcall imm:$dst)]>;
> }
>
>
> This is probably not the best way to fix this, though. Thinking about
> it, I'm not sure what a proper fix would be. For small targets, just
> using rcall is fine. However, for bigger targets, one would want to use
> rcall whenever possible, or fall back to call otherwise. But I don't
> think you can actually know (in all cases) if using rcall is possible
> until after assembling, right?
>
> Gr.
>
> Matthijs
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAlJFVP8ACgkQz0nQ5oovr7w0UwCfWb4uYGSCZdUDxKNB0j7HHRy4
> 4FIAn0kb5n48bjTB996tiqYbm2XqaX0R
> =3NHj
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>
|
