kinke
commented
4 years ago An 8-bit controller target? Interesting. :) - What triple do you use to generate the .ll files? I guess we'd only need to enable the AVR target for our LLVM to support direct .o emission and linking via -gcc=avr-gcc.
Have you checked whether the functions are emitted into separate sections in the object file? E.g., llvm-readelf --sections myobject.o. That's a prerequisite for ld's stripping via --gc-sections. I don't know how you generate the .o files from the .ll files, but as it's probably an LLVM tool, there might be a -function-sections (and -data-sections) command-line option for that.
WebFreak001
JohanEngelen
I'm currently using LDC to generate LLVM IR files which I then generate to AVR compatible .o files and link using avr-gcc (calling avr-ld)
Now my problem is that I heavily use templated structs without fields with all methods static and force inline for syntactic sugar, but this generates around 3000 lines of useless LLVM IR in my project right now which blows up the resulting ELF file by over 2KB (increasing flash time by several seconds and leaving me with a lot less flash memory)
For reference my code:
My templated struct for transparent volatile pointers
```d // all this code does is translating this C define to D: // #define MEM(addr) (*((volatile T*)addr)) // so you can do // #define MEMX MEM(0x20) // and then use it using // MEMX = 4; // MEMX |= 8; /// Helper struct to automatically call volatileStore and volatileLoad on assignment/reading of pointers private template VolatileRef(T, alias addr) { private struct VolatileRef { alias get this; pragma(inline, true): // TODO: the following functions still make it into the resulting HEX file, even though they are unused if always inlined // they should be removed from the hex file somehow, but they don't get stripped or removed by -Wl,--gc-sections static T* ptr() { return cast(T*)(addr); } static T get() { return volatileLoad(ptr); } static void opAssign(T value) { volatileStore(ptr, value); } static auto opOpAssign(string op)(T value) { T ret; mixin("volatileStore(ptr, ret = cast(T)(volatileLoad(ptr) " ~ op ~ " value));"); return ret; } } } // enum MEM(alias addr) = VolatileRef!(ubyte, cast(ubyte*)addr); // there are like 200 of these defines in my code: // enum MEMX = MEM!0x20; // MEMX = 6; ```It would be great if it was possible to make LDC somehow maybe not even emit the functions as LLVM IR but instead always inline the IR code directly so it works cross module before optimization as well. (because of #3126)
Is there maybe an existing way (using LLVM) to strip out the unused methods? I am using
--fvisibility=hidden, so they are actually marked as hidden in the .ll files but they are still being built and still exist in the final ELF file. I also tried--internalizebut that made the main function non-accessible or renamed it to something which the linker couldn't find. (the .ll file still was huge though)Otherwise it would be great to have a ldc.attributes.forceInline or something similar. Or maybe this would be fixed along with #2968 ?
Otherwise LDC is working great with embedded development using AVR! :)