Search |
 |
|
 |
| Author |
Message |
|
|
 Posted: Jun 23, 2011 - 01:39 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
Hi, I just did a Win32-build of avr-gcc-4.6.1 (release candidate) and am playing around with it.
Trying to use link time optimization (LTO) I run into ld complaining about "unrecognized option -plugin" similar to reported in
http://sourceware.org/PR12742
which is reported against binutils 2.20.
My build uses binutils 2.21.
Did anyone ever try to use LTO with avr-gcc on Windows?
If anyone feels inclined to play around with Windows avr-gcc-4.6.1, too, I can post a link to get it together with some notes.
The build is just indended to get a feeling of quality of 4.6.1. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 25, 2011 - 01:36 PM |
|
Joined: Mar 01, 2001
Posts: 4952
Location: Rocky Mountains
|
|
I seem to recall I tried once. Didn't get very far, but now I don't remember why...
So, what's your feeling of quality of 4.6.1? |
_________________
Eric Weddington
Marketing Manager
Open Source & Community
Atmel
|
| |
|
|
|
|
|
|
Posted: Jun 25, 2011 - 03:16 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
EW wrote:
I seem to recall I tried once. Didn't get very far, but now I don't remember why...
In my case it's missing dlopen support in the build environment I use. I tries to hack binutils without success (there is a dlopen wrapper on the web), so I will have to extend the build environment.
Quote:
So, what's your feeling of quality of 4.6.1?
It's still outperformed by 3.4.6, similar to any avr-gcc 4 I ever tried so far. For some sources it produces code +15% in size.
One of the main reasons appears to be PR46278 (fake X+const addressing). Theoretically, it's easy to solve but in AVR-practice it's very hard. Seems that Denis is working on it.
Moreover, PR46779/PR45291 (missing reloads for fp subregs) is not yet fixed so that I would not use it in a real application (similar applies to 4.5 and trunk). I have a patch to review as you know but it's got stuck somewhere in the pipe...
To test I am using my "Asteroids+Snake on Scope Clock" application. I have no other larger applications to test. And at the moment I feel more inclined to develop avr-gcc than to develop using avr-gcc.  |
|
|
| |
|
|
|
|
|
|
Posted: Jun 25, 2011 - 04:13 PM |
|
Joined: Jun 26, 2006
Posts: 625
Location: San Luis Valley, Colorado ( 2,318m )
|
|
|
SprinterSB wrote:
If anyone feels inclined to play around with Windows avr-gcc-4.6.1, too, I can post a link to get it together with some notes.
The next week or so is looking pretty crazy, but following that I should be free to do some looking. I've no particularly large projects to test against, but, then, variety helps.
If you are up to getting some notes together I will certainly add my two cents. I am especially interested in the possibilities provided by LTO ( assuming it can be made to work ).
Martin Jay McKee |
_________________
As with most things in engineering, the answer is an unabashed, "It depends."
|
| |
|
|
|
|
|
|
Posted: Jun 25, 2011 - 07:12 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
mckeemj wrote:
SprinterSB wrote:
If anyone feels inclined to play around with Windows avr-gcc-4.6.1, too, I can post a link to get it together with some notes.
The next week or so is looking pretty crazy, but following that I should be free to do some looking. I've no particularly large projects to test against, but, then, variety helps.
If you are up to getting some notes together I will certainly add my two cents.
Ok, here is is:
Sources
"Installing"- It's just a zip archive that I dropped at sourceforge: http://sourceforge.net/projects/mobilec ... p/download . It's not self-extracting, so you need (un)zip. The size of the zip is 26MB; the size on disc is 76MB.
- Unpack to a place you prefer. The zip will unpack to a directory "gcc-4.6.1-mingw32". You can rename it if you like.
- To "uninstall" just remove that directory.
Using- To use the tools you can simply give the absolute path like c:\gcc-4.6.1-mingw32\bin\avr-gcc[.exe] or change PATH. You can add it to the end of PATH and call avr-gcc-4.6.1 so it does not matter if avr-gcc is hidden behind you favourite avr-gcc.
Please let me know if you get it to work or run into problems.
mckeemj wrote:
I am especially interested in the possibilities provided by LTO ( assuming it can be made to work ).
I'll have to extend the build environment so get LTO to work. At the moment it works only for GCC, but the linker fails to call a plugin to callback GCC at link time. Easiest way to benefit from LTO is using native build on Linux, native cygwin build should work also.
Actually LTO is not an optimization at link time. GCC writes intermediate representation (IR) to the object file. At link time, the linker makes a callback to GCC. GCC then deserializes the IR and does the compilation again, just based on the IR. So it's similar to giving all the sources on the command line - cum granum salis, e.g. a library can also contain LTO info.
Therefore, LTO is rather "recompile at link time" than "optimize at link time". This means that the original assembler s-files and code in o-object files is paper-waste... |
Last edited by SprinterSB on Oct 21, 2011 - 05:38 PM; edited 2 times in total
|
| |
|
|
|
|
|
|
Posted: Jun 25, 2011 - 10:24 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
EW wrote:
So, what's your feeling of quality of 4.6.1?
Moreover, -mint8 is consistently broken in all versions 4.5+ |
|
|
| |
|
|
|
|
|
|
Posted: Jun 27, 2011 - 02:14 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
SprinterSB wrote:
EW wrote:
So, what's your feeling of quality of 4.6.1?
Moreover, -mint8 is consistently broken in all versions 4.5+
Doesn't sound like a great loss... of course anything in "production" should issue a legible error message and a clear note in the documentation...
0.02E
JW |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2011 - 09:11 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
mckeemj wrote:
If you are up to getting some notes together I will certainly add my two cents. I am especially interested in the possibilities provided by LTO ( assuming it can be made to work ).
I gave it a second try and added the dlopen wrapper to the build environment. The compiler builds fine but ld fails to operate correctly on plugin, i.e. it cannot correctly dlclose or unload the lib. So I stopped trying to get LTO to work in canadian cross. Perhaps the dlfcn-win32 I found on the web is just garbage...
AFAIK Eric builds under cygwin, so maybe the next WinAVR release (4.6.2?) comes with functional LTO. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2011 - 11:06 PM |
|
Joined: Jun 26, 2006
Posts: 625
Location: San Luis Valley, Colorado ( 2,318m )
|
|
|
SprinterSB wrote:
The compiler builds fine but ld fails to operate correctly on plugin,
Thanks for the short write up, BTW, I should be able to get started with some testing this weekend. As to LTO, well, it's a shame it seems to be something of a pain right now; but if I am having an especially slow day perhaps I'll take a look at the compilation myself.
On a slightly different tack... I have my own list, but does anyone have anything specific they would like me to check in 4.6.1? It sounds like code size hasn't improved ( shame... ) but there may be more subtle things.
SprinterSB wrote:
Moreover, -mint8 is consistently broken in all versions 4.5+
I agree with Jan that this option is unlikely to really matter in most cases. Still, I don't like the idea of something so "available" to break code with. I can see plenty of people complaining about problems when they are "optimizing" - or not, I've been known to be overly pessimistic at times as well.
Martin Jay McKee |
_________________
As with most things in engineering, the answer is an unabashed, "It depends."
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2011 - 06:45 AM |
|
Joined: Mar 01, 2001
Posts: 4952
Location: Rocky Mountains
|
|
|
SprinterSB wrote:
AFAIK Eric builds under cygwin, so maybe the next WinAVR release (4.6.2?) comes with functional LTO.
Hi Johann,
Actually I build under MinGW for the most part (for sure for binutils, gcc, avr-libc). Right now I'm looking at using gcc 4.6.1, unless there will be a 4.6.2 release in the next month. Also, I'll be using the latest binutils release, 2.21.1. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2011 - 05:55 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
Findings. Lengthy, boring, and touches various issues, not necessarily relevant to the original post.
I took one of the projects I am working on and tried to run it through 4 different builds: my "production" toolchain is WinAVR20071221 (yes, this project runs for quite some time  ), WinAVR20100110, AVR Toolchain (should be identical to AS5) and the "4.6.1 preview" from above. There are 3 processors in the device, an ATMega2561 and two ATMega8. Various stuff is involved: heavy use of bitfields, extensive use of inline assembler/macros, use of the 64kW+ FLASH memory stuff, various mods on the linker script, algorithmically intensive routines, unusually lengthy (partially generated) functions. On the other hand, library use is minimized and function pointers use (which appears to trigger a couple of problems in the 64kW+ devices) is also minimal.
While doing this, and testing the result for expected functionality, I discovered two flaws of our "standard" inline assembler macros (circular buffer manipulation), which were revealed "thanks" to more aggressive optimization of the newer versions of avr-gcc, so the exercise was worth doing it. (One was an "r" constraint used where "d" should've been; other was a register assigned through input parameter seen by the compiler as constant while it was changed in the inline asm).
I also discovered the flaw in the "Toolchain"'s startup, reported elsewhere.
Findings pertinent to the "4.6.1 preview":
- - progmem must be const -- this was major pain in the ***, requiring adding const to hundreds of lines, sometimes requiring investigation how some of the typedefs are used. I understand the reason (some of my PROGMEM-tagged variables were already const, but I was lazy to do that consistently so far); but I would warmly welcome an (interim, perhaps, and accompanied by a nagging warning) switch to alleviate this need for similar situations where existing codebase is to be compiled.
- -msize does not work. It probably stopped work earlier; I don't miss it (don't even know what does it do), it just broke my usual make process
- -time does not work (is silently ignored). Probably never worked, I just wanted to use it to find out what's wrong - see next item
- compilation (-c) of a bigger source (~250k, ~8kLOC) took inordinate time - ~50sec instead of the usual 7-8 sec. Further investigation revealed, that -S took in fact LESS then previously (cca 3sec vs. cca 5sec); it was the assembling which lasted much much longer. Finally narrowed the problem down to the generation of listing file, using -Wa,-adhlns.
- the 'M8-s' firmware is appended to the 'M2561 which is then able to "burn" those two M8-s immediately after being uploaded.
So, first the M8-s firmware is translated into respective .hex, which in turn is converted back into a single-section "object" (.elf) using objcopy (binary in, elf out, explicit padding and filling, explicitly renamed section). This is then linked "normally" to the 'M2561's firmware. I found this method as logically superior to the "usual" way of converting .hex to .C source which is then compiled/linked in the "usual" way.
This worked well with the '20071221, but in the "preview" stopped working (maybe it stopped meantime, did not check). The "preview"'s linker complains, that the such created "objects" are not avr:6 architecture, and refuses to link.
So I learned about the -B switch of objcopy, but it refuses to work when .hex is the input file. This is weird, as .hex is IMHO as good a binary input as .bin. Now my workaround is first converting hex to bin and then bin to obj.
I would submit a feature request to enable -B for .hex (and other similar) types of input; I just would like to ask the more knowledgeable developers here to comment on whether there is or is not any logical flaw in this request.
Below are the compiled sizes. I did not experiment with using different command-line switches relevant to the optimizations, all were with "-Os -funsigned-char -funsigned-bitfields -fpack-struc
t -fshort-enums -std=gnu99". While there is some improvement throughout the years, I don't think I am going to abandon my trusty 2007-vintage WinAVR just for the 2-3% code size decrease.
I have no means to benchmark "speed". (The one difference in data size in one of the 'M8 between the 2007 vintage and others is due to use of alignment on some data to a 0x40 boundary: the 2007 vintage adds the padding into the total data size while others don't.)
Enjoy!
JW
Code:
----------------
avr-gcc (GCC) 4.6.1 20110620 (prerelease)
ATMega2561: Program: 144581 bytes (55.2% Full) Data: 2922 bytes (35.7% Full)
ATMega8/1: Program: 4940 bytes (60.3% Full) Data: 303 bytes (29.6% Full)
ATMega8/2: Program: 3084 bytes (37.6% Full) Data: 141 bytes (13.8% Full)
----------------
AVR Toolchain avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.2.3_314) 4.5.1
ATMega2561: Program: 144829 bytes (55.2% Full) Data: 2922 bytes (35.7% Full)
ATMega8/1: Program: 5010 bytes (61.2% Full) Data: 303 bytes (29.6% Full)
ATMega8/2: Program: 3118 bytes (38.1% Full) Data: 141 bytes (13.8% Full)
----------------
WinAVR20100110 avr-gcc (WinAVR 20100110) 4.3.3
ATMega2561: Program: 148379 bytes (56.6% Full) Data: 2922 bytes (35.7% Full)
ATMega8/1: Program: 5158 bytes (63.0% Full) Data: 303 bytes (29.6% Full)
ATMega8/2: Program: 3162 bytes (38.6% Full) Data: 141 bytes (13.8% Full)
----------------
WinAVR 20071227 avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
ATMega2561: Program: 148267 bytes (56.6% Full) Data: 2922 bytes (35.7% Full)
ATMega8/1: Program: 5032 bytes (61.4% Full) Data: 352 bytes (34.4% Full)
ATMega8/2: Program: 3198 bytes (39.0% Full) Data: 141 bytes (13.8% Full)
|
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2011 - 08:58 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
ad 1.
There were some inconsistencies in progmem handling that caused PR44643. With just a warning you could run on a "foo causes section type conflict" error, witch is less comprehensible message. I thought I was strict with const+progmem in my programs, too, but also found some complaints
I'd like to change the progmem stuff even further so that it works properly on types -- or throw error on types because progmem on types has never been documented. But there is stuff like prog_char in avr-libc which even encourages users to use undocumented, undefined features...
Moreover, I'd like to change progmem inerts so that string merging was possible and implementing progmem pragma would be straight forward.
ad 2.
Anatoly removed -msize; just use -dp.
ad 3.
Nothing avr specific
ad 4.
hmmm. Such hog is maybe a binutils issue and you could asm. Or the generated lss is extremely big because of inlining, macro expansion etc.
ad 5.
Again binutils. You could generate bin out of elf directly, without intermediate ihex.
Maybe ask in binutils list why thes changed it or if there is a replacement with -B, -I, -O, -F, --alt-machine or whatever.
For the size, did you try -fno-split-wide-types or -fno-inline-small-functions?
mckeemj wrote:
SprinterSB wrote:
The compiler builds fine but ld fails to operate correctly on plugin,
but does anyone have anything specific they would like me to check in 4.6.1?
It's already good news if it simply works
Quote:
SprinterSB wrote:
Moreover, -mint8 is consistently broken in all versions 4.5+
Still, I don't like the idea of something so "available" to break code with.
It doesn't break code, it shreds the compiler. I don't know anything on correctness of code with -mint8; the last time I used it was with 3.4.6.
Johann |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2011 - 05:35 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
SprinterSB wrote:
ad 1.
There were some inconsistencies [...]
As I said, I understand the reasons; I just would like to have an option to fall back willingly to the "old order". As a mere user, I of course cannot see how easy or difficult is this to accomplish.
SprinterSB wrote:
I'd like to change the progmem stuff even further so that it works properly on types -- or throw error on types because progmem on types has never been documented.
I use PROGMEM in typedefs quite extensively and never run into problems. Can you please show me an example where it would fail?
Honestly, it even did not occur to me that this would not work in typedefs so I did not bother to check in documentation - it would be completely illogical. Again, mind, I said this from an user's point of view (the user wants thing to work in a logical way, he does not care about the formal difference between qualifier and attribute - the latter being a non-standard and not-that-well-defined extension of gcc anyway).
SprinterSB wrote:
ad 4.
hmmm. Such hog is maybe a binutils issue and you could asm.
Yes, it is a gas issue, but as a user, I don't quite care that binutils and gcc are formally separate projects. I as a user see this as a flaw of the "package".
SprinterSB wrote:
Or the generated lss is extremely big because of inlining, macro expansion etc.
(Just to make sure we are talking about the same thing, the issue is NOT the listing generated by disassembling using objdump (usually suffixed .lss). The issue is, that it takes inordinately long time to assemble if the assembler is commanded to generate a list file, usually with .lst suffix.)
The .lst file - which takes around 50 secs to generate - is 1.5 megabytes long. The '2007 toolchain generates a 0.9mb .lst file in some 3 seconds. I see in the "new" .lst file a lot of garbage - seems like the whole C source appended at the beginning - but I honestly don't intend to investigate the reason, I just see this to be a flaw I am reporting about here and now.
SprinterSB wrote:
ad 5.
Again binutils.
And, again, I am the user of the package...
SprinterSB wrote:
You could generate bin out of elf directly, without intermediate ihex.
Maybe I could, but I need the hex for other purposes too... 
SprinterSB wrote:
Maybe ask in binutils list why thes changed it
I don't think there is really a reason to ask specifically this.
SprinterSB wrote:
or if there is a replacement with -B, -I, -O, -F, --alt-machine or whatever.
As I said, I do have a solution with -B, except that it annoys me that it does not accept hex. I've looked into objcopy.c, and it's specifically written so that -B with any other input_target than "binary" throws "Warning: input target 'binary' required for binary architecture parameter." and ignores the -B.
I just would like to know whether there might be a specific reason why ihex (or srecord or similar) is not good for -B. If you or anybody other knows of none, I would then perhaps nag the binutils people.
SprinterSB wrote:
For the size, did you try -fno-split-wide-types or -fno-inline-small-functions?
Code:
----------------
avr-gcc (GCC) 4.6.1 20110620 (prerelease)
ATMega2561: Program: 144581 bytes (55.2% Full) Data: 2922 bytes (35.7% Full)
ATMega8/1: Program: 4940 bytes (60.3% Full) Data: 303 bytes (29.6% Full)
ATMega8/2: Program: 3084 bytes (37.6% Full) Data: 141 bytes (13.8% Full)
with -fno-split-wide-types
ATMega2561: Program: 144337 bytes (55.1% Full) Data: 2922 bytes (35.7% Full)
ATMega8/1: Program: 4956 bytes (60.5% Full) Data: 303 bytes (29.6% Full)
ATMega8/2: Program: 3114 bytes (38.0% Full) Data: 141 bytes (13.8% Full)
with -fno-inline-small-functions
ATMega2561: Program: 144743 bytes (55.2% Full) Data: 2922 bytes (35.7% Full)
ATMega8/1: Program: 4974 bytes (60.7% Full) Data: 303 bytes (29.6% Full)
ATMega8/2: Program: 3100 bytes (37.8% Full) Data: 141 bytes (13.8% Full)
Jan |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2011 - 10:45 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
wek wrote:
SprinterSB wrote:
ad 1.
There were some inconsistencies [...]
As I said, I understand the reasons; I just would like to have an option to fall back willingly to the "old order". As a mere user, I of course cannot see how easy or difficult is this to accomplish.
With that option you would run into other problems like ICE as mentioned in PR44643. I don't think you prefer ICE over proper error message.
wek wrote:
SprinterSB wrote:
I'd like to change the progmem stuff even further so that it works properly on types -- or throw error on types because progmem on types has never been documented.
I use PROGMEM in typedefs quite extensively and never run into problems. Can you please show me an example where it would fail?
That's PR38342 that has been closed just recently as "Won't Fix". It's agreed by the maintainers nothing to do about it: neither throw an error nor support progmem in types. If you use that feature it might silently break your code in future versions of gcc.
wek wrote:
Honestly, it even did not occur to me that this would not work in typedefs so I did not bother to check in documentation - it would be completely illogical.
You don't change a type layout like with 'packed', I don't see a reason for havon 'progmem' for types. A char is exactly the same, no matter wether it's placed in flash, in ram or in eeprom or in .noinit or wherever.
wek wrote:
SprinterSB wrote:
Or the generated lss is extremely big because of inlining, macro expansion etc.
Just to make sure we are talking about the same thing [...]. The issue is, that it takes inordinately long time to assemble if the assembler is commanded to generate a list file, [...]
The .lst file - which takes around 50 secs to generate - is 1.5 megabytes long. The '2007 toolchain generates a 0.9mb .lst file in some 3 seconds. I see in the "new" .lst file a lot of garbage - seems like the whole C source appended at the beginning
If you request garbage, you get garbage
Maybe it's more informative to dump .s -fverbose-asm for your needs (at you option /without/ -g).
And as the .ls-whatever is quite big, how do you see that it's a gas issue and not because of some (file system) cache or buffer limitations in your OS? You might want to try -pipe with programs that big or omit -g if don't really need -g (I never needed that garbage on embedded). |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2011 - 12:03 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
I now also confirmed that both linker problems presented here and here persist in both the "AVR Toolchain" and your build.
---
As per PROGMEM in typedefs: I disagree with most what you wrote about this both in various threads here and on the mailing list. From the user viewpoint, I find it just logical that a method to define a storage class (or named space as you call it) works with typedefs as well. Also this is how these work in other 8-bit compilers I know of. I understand that supporting that in avr-gcc is troublesome; I just repeat that most I post here is from the user point's of view, ignoring what that implies for the supporters.
---
Similarly to my request to support a command-line option allowing to willingly revert to the "old", "const-less" state. I understand that this might be a problem for you as the developer, but I assure you that there will be more *users* requesting backward compatibility at the cost of potential problems (they possibly never experineced in the past and never will in the future too). A nagging warning may be issued when this option is used, notifying the user of the known issues with this.
---
Johann wrote:
If you request garbage, you get garbage
The -Wa,-adhlns=filename.lst is one of the compiler flags "supplied" by the standard makefile template from mfile. Again, as a user I expect certain consistency in what the commandline flags mean. In fact, I quote often inspect the so generated .lst files and never thought they may be "garbage" so far.
Johann wrote:
And as the .ls-whatever is quite big, how do you see that it's a gas issue and not because of some (file system) cache or buffer limitations in your OS?
I am a mere user, I don't know that; however, I never found significant performance jumps with files/data structures in the order of hundreds of kilobytes to few megabytes on a contemporary PC.
I report behaviour different than expected and am willing to cooperate in whatever corrective action there might be, but I can only do as much as my limited knowledge of the things allows.
JW |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2011 - 01:54 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
wek wrote:
The -Wa,-adhlns=filename.lst is one of the compiler flags "supplied" by the standard makefile template from mfile. Again, as a user I expect certain consistency in what the commandline flags mean. In fact, I quote often inspect the so generated .lst files and never thought they may be "garbage" so far.
Okay so I played with this a bit and it appears, that while in the older "installations" the -ah portion of that switch (include high-level language listing) simply did not work at all, it does work in your "installation", and that single "sub-flag" is indeed what causes the extremely long assembly times.
So, I'd suggest to Joerg to modify the makefile template in mfile accordingly (namely to use -Wa,-adlns); and to whomever would emit a new package (Eric?) to place a remark to the release notes saying that users who update should remove the "h" from their old makefiles.
I wonder whether any of them is following this thread... especially for mfile there's no "official" bug tracker, even if this time I think I would be able to produce a patch...
JW |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2011 - 02:27 PM |
|
Joined: Apr 25, 2004
Posts: 3808
Location: Denmark
|
|
Jorg is on vacation
/bingo |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2011 - 02:48 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
| I envy him... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2011 - 04:12 PM |
|
Joined: Oct 29, 2006
Posts: 2640
|
|
|
SprinterSB wrote:
Actually LTO is not an optimization at link time. GCC writes intermediate representation (IR) to the object file. At link time, the linker makes a callback to GCC. GCC then deserializes the IR and does the compilation again, just based on the IR. So it's similar to giving all the sources on the command line - cum granum salis, e.g. a library can also contain LTO info.
Therefore, LTO is rather "recompile at link time" than "optimize at link time". This means that the original assembler s-files and code in o-object files is paper-waste...
What is the relationship, if any, between LTO and --relax? |
_________________
Michael Hennebry
Iluvatar is the better part of Valar.
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2011 - 04:31 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
wek wrote:
5. the 'M8-s' firmware is appended [...]
I would submit a feature request to enable -B for .hex (and other similar) types of input [...]
And I did.
And a big shame on me. Turned out, this is already implemented in binutils 2.21... By mistake, for the "tests" I used the same avr-objcopy of WinAVR20100110, which of course is older... 
JW |
|
|
| |
|
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
