LTO in AS6.1B

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel,

You may want to read this:

https://www.avrfreaks.net/index.p...

LTO is interesting but it looks like you cannot use it in a standard AS6.1B installation.

Now I mention it I have a vague feeling of deja-vu and the fact that Georg Johann-Lay (SprinterSB) may have already pointed this out?

EDIT: Ah yes I didn't dream it:

https://www.avrfreaks.net/index.p...

So I assume you are already aware of this? It does mean you'll need that PR fix before 6.1 final ships out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read :P

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Backporting it right away - should be available in the final release.

Regards

Senthil

 

blog | website

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Re-read that thread I linked to. Seems Alan now got it to work by putting the 6.1B toolchain in a path without spaces but the results were very disappointing. I kind of wonder if it actually worked at all?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I posted my makefile in the other thread, with any luck one of my other compiler options doesn't work well with LTO and I just don't know enough about it. I'd love to see it work as well as or better than whole program optimization...

Thanks,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alan,

I'd be extremely interested in seeing more about this, as I've been wanting to play with LTO for a long time. Does the size increase with a basic LED flasher application? Have you looked at the MAP/LSS files to see what's gotten larger?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean,

I just realised there's an easy way to try this. If you use "modern" Windows it has a mklink command but I use XP so I used the junction.exe from sysinternals.com to do the following:

C:\>junction c:\avrgcc "c:\Program Files\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.2.876\avr8-gnu-toolchain"

That puts a virtual copy of the toolchain in c:\avrgcc with the tools themselves in c:\avrgcc\bin. I then did:

C:\>set path=c:\avrgcc\bin;%path%

After that I could confirm that 4.7.2 was active:

C:\>avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=c:/avrgcc/bin/../libexec/gcc/avr/4.7.2/lto-wrapper.exe
Target: avr
[snip]
Thread model: single
gcc version 4.7.2 (AVR_8_bit_GNU_Toolchain_3.4.2_876)

I then built this (rather artificial!) code:

#include 
#include 

char data[512] = "hello";
char buff[512];

int main(void)
{
	DDRB = 0xFF;
	while(1) {
		PORTB ^= 0xFF;
		_delay_ms(100);
	}
} 

Without -flto in CFLAGS/LDFLAGS I get:
Size before:

AVR Memory Usage
----------------
Device: atmega16

Program:     686 bytes (4.2% Full)
(.text + .data + .bootloader)

Data:       1024 bytes (100.0% Full)
(.data + .bss + .noinit)

After adding the options:

AVR Memory Usage
----------------
Device: atmega16

Program:     136 bytes (0.8% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)

As I say this was a bit artificial as there were huge chunks of data in .data and .bss but at least LTO has achieved something ;-)

EDIT oh and if I remove the globals and the -flto it builds to 136+0 anyway.