Le vendredi 20 septembre 2013 03:08:10 Sylvain BERTRAND a écrit : > Hi, > > ---- > > I wonder if the internals of tinycc can easily supports basic > optimization passes. The idea is not to compete with gcc and its > hundred of passes, but my guess is that very few optimization > passes would be required to give a significant performance boost > to generated code. Just need to select the "right" ones... > > As a C writer, I have been thinking about the "variable aliasing" > pass over a compilation unit. Because a lot of code use many C > variables to reference the same actual variable to make code more > readable. Then in my ignorant mind I see a lot of wasted > registers and stack space and a significant performance loss at a > global scale. Wrong?
I'm not familiar with optimization but I would guess it would have a non negligeable impact on tcc's performance. If you want basic optimization you could try -O1 switch of gcc or clang. Unless the cost of an optimization is negligeable, I think adding it to tcc is not a good idea. Many people are interested in tcc because of its fast compilation so I would say it's more important to keep it fast than to make the generated code better. > > I thought about a "constant folding" pass but I'm not convince > this pass would give a significant boost over my perception of > general C code. There is constant propagation in tcc, I don't know if it is what you are talking about. > > ---- > > Another thing is about inline assembly. Indeed, I happened to > write some code without a libc for x86-64, namely directly wired > to linux syscalls. Quickly the need of assembly caught up. I > could use an assembler (gas, yasm...) but then I would pay the > price of the C calling convention (prolog/epilog/parameters > passing) and the call/ret. The whole point of inline assembly is > to avoid to "dance" too much with the registers/stack because of > the function call. On modern architectures, is the performance > loss of such a "dance" worth the complexity of inline > assembly? > > I know it would mean, at least for x86-64, to write an > assembler/use an external assembler in/for the architecture > backend. > > On that subject, to work around the complexity of an inline > assembly infrastructure, I notice that it seems inline assembly > is interesting in not that many cases. We could imagine to extend > per architecture the C language with builtin functions/new > operators/keywords. For instance for atomic operations, syscalls... > Am I missing a case we would really want which makes this work > around really and obviously impractical? There is already inline assembly in tcc for i386 and x86-64. However, the support is not fully complete. > > ---- > > Of course, all that is from my perspective, meaning with > 0-experience on compiler programming. The idea is to achieve > a reasonable global performance level compared to gcc on > "classic" system loads. To lower the distance, code "hotspots" > would be written in assembly (cf ffmpeg). > > thanks, Best regards, Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
