(1st, a maximum of thumb up to P.A. Bigot and others for this work)
I'm trying to use the Link Time Optimization that GCC provides, thus I'm adding the "-flto" during the comiplation and the link edition. But this last part fails, it says that "lto1" is segfaulting, then I've the message from ld "lto-wrapper failed". Does this optimization option available with mspgcc ? Is my "-flto" invocation faulty ?
The mspgcc version I'm using is compiled from source and patched with correctoins 352 and 357:
msp430-gcc (GCC) 4.7.0 20120322 (mspgcc dev 20120911)
Thank you in advancve for any information about this subject.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
mspgcc (which is no longer maintained) does not support link-time optimization with that flag. You need to switch to the upstream GNU msp430-elf port done by Red Hat a year or two ago. I believe that toolchain does support -flto. You can get a copy from Texas Instruments or compile the upstream releases yourself, if your OS distribution does not provide a pre-built msp430-elf toolchain.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm aware of the "mspgcc not maintained but red-hat gcc" story...
In fact I've a big application that run well but become too large. I have some algo to add, so I was trying this quick solution (-flto) before porting my src to another compiler and try. But it is some work, and many tests...
Do you have any idea what code size gain can I roughly expect by using red-hat gcc ? ccs or any other proprietary solutions ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I last compared (over a year ago), I got a small code size increase with msp430-elf. More recent optimizations may have reduced the increase or made msp430-elf generate smaller code. The cause of increased application size for most cases is not the compiler but the replacement libc, newlib, which is more standard conforming and less size-concerned than msp430-libc. If you build a custom newlib with special options as in the script provided by BSP430 the size increase is significantly reduced; there are also tricks you can play with the system interface to reduce the size. Poke around in BSP430's build system for flags like -ffunction-sections -fdata-sections -Wl,-gc-sections though -flto might supersede those.
When I use MSP430 I use msp430-elf, not mspgcc, and I do recommend updating for any system that's in active development.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I can resonnably expect some size gain by using msp430-elf with the tailored libc and the -flto option I guess. Whatever, I have to port my code to another compiler so I think i'll start this work for msp430-elf. And after a quick look to your bsp430 repository, I think there's all the informations i'll need to help me... another big thumb up is in preparation...
Peter, thank you so much for your time, and your work. Hope your freelance business run well because you deserve it !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
(1st, a maximum of thumb up to P.A. Bigot and others for this work)
I'm trying to use the Link Time Optimization that GCC provides, thus I'm adding the "-flto" during the comiplation and the link edition. But this last part fails, it says that "lto1" is segfaulting, then I've the message from ld "lto-wrapper failed". Does this optimization option available with mspgcc ? Is my "-flto" invocation faulty ?
The mspgcc version I'm using is compiled from source and patched with correctoins 352 and 357:
msp430-gcc (GCC) 4.7.0 20120322 (mspgcc dev 20120911)
Thank you in advancve for any information about this subject.
mspgcc (which is no longer maintained) does not support link-time optimization with that flag. You need to switch to the upstream GNU msp430-elf port done by Red Hat a year or two ago. I believe that toolchain does support -flto. You can get a copy from Texas Instruments or compile the upstream releases yourself, if your OS distribution does not provide a pre-built msp430-elf toolchain.
Thank you (again) Peter.
I'm aware of the "mspgcc not maintained but red-hat gcc" story...
In fact I've a big application that run well but become too large. I have some algo to add, so I was trying this quick solution (-flto) before porting my src to another compiler and try. But it is some work, and many tests...
Do you have any idea what code size gain can I roughly expect by using red-hat gcc ? ccs or any other proprietary solutions ?
When I last compared (over a year ago), I got a small code size increase with msp430-elf. More recent optimizations may have reduced the increase or made msp430-elf generate smaller code. The cause of increased application size for most cases is not the compiler but the replacement libc, newlib, which is more standard conforming and less size-concerned than msp430-libc. If you build a custom newlib with special options as in the script provided by BSP430 the size increase is significantly reduced; there are also tricks you can play with the system interface to reduce the size. Poke around in BSP430's build system for flags like
-ffunction-sections -fdata-sections -Wl,-gc-sectionsthough-fltomight supersede those.When I use MSP430 I use msp430-elf, not mspgcc, and I do recommend updating for any system that's in active development.
So I can resonnably expect some size gain by using msp430-elf with the tailored libc and the -flto option I guess. Whatever, I have to port my code to another compiler so I think i'll start this work for msp430-elf. And after a quick look to your bsp430 repository, I think there's all the informations i'll need to help me... another big thumb up is in preparation...
Peter, thank you so much for your time, and your work. Hope your freelance business run well because you deserve it !