Re: [Tinycc-devel] C99 token pasting
Thomas Preud'homme wrote: On April 12, 2014 9:53:51 PM GMT+08:00, grischka gris...@gmx.de wrote: Good, however note that the mechanism to perform token pasting via tcc_open_bf(tcc_state, :paste:, cstr.size); is extremely slow and per se has a good share in making current tcc about twice as slow compiling itself compared to 0.9.25. You mean even without this patch tcc is already slower than for 0.9.26? No, I meant 0.9.25. ;) However looking more closely the results for the current tcc are more like at ~135% compared to those with 0.9.24/25. Most of that seems due to changes/complications in the preprocessor, such as: http://repo.or.cz/w/tinycc.git/commitdiff/00f093276030ed87c3992a5bde22673f691b08c9 http://repo.or.cz/w/tinycc.git/commitdiff/0f0ed4a8bf2b6f6bdcab1a46c34c6f54005bf34e http://repo.or.cz/w/tinycc.git/commitdiff/44e84bb22adc78844ac1c08e6f8a6d0278a942d8 Your patch would add additional 15-20%: http://repo.or.cz/w/tinycc.git/commitdiff/6e56bb387db8af055ff6de71a23b270de55c3dc8 Also I just noticed it breaks the test case given in http://repo.or.cz/w/tinycc.git/commitdiff/dd5630ff95b8dc47ab3b5ef3f167f3342da79a77 There seems btw a similar patch at http://repo.or.cz/w/tinycc.git/commitdiff/185fba418978aabef36765fdfaf24d516f1a9f33 Now I observe that (in self compilation) token pasting happens 3113 times, however the fix (which as the comment suggests is to improve certain cases of token pasting) runs similar code additional 22669 times. This raises some questions. o_O Strange indeed. I see two ways to reduce the cost of this patch. First one is to rename next_nomacro1 become next_nomacro2 that would take a char * pointer to the buffer to parse for tokens and create a next_nomacro1 wrapper for compatibility. Then tcc_open_bf would not be necessary. It could maybe allow to remove another tcc_open_bf in the same function. A second solution would be to create a new function capable of identifying all the cases where a space needs to be added. That would duplicate part of what next_nomacro1 already know about tokens but should be quite a small function and would be faster. Maybe the first change should be done anyway if choosing the second approach for the already existing call to tcc_open_bf in macro_twosharps. And solution 3 (my favorite): Just hope for someone to rewrite those tiny five macro_subst_stuff functions from scratch altogether, finally. Until then, why not add that space regardless of what token follows (even if it doesn't look exactly like gcc -E). But then only if a ## paste did actually happen and then only in tcc -E mode. Otherwise there is no point to add spaces, they're all removed anyway. --- grischka Thanks for monitoring performance regression grischka. Cheers, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Support for hidden symbols?
Hi, On Sat, 12 Apr 2014, Austin English wrote: I recently revisited compiling Wine with TinyCC. I've got some patches for wine for that, but my current blocker is a lack of support for hidden symbols on tcc: Even with that fixed I'll predict some more blockers for wine. It's not exactly one of the most trivial (and C conformant) program packages. And well, wine has some quite performance critical components, so what would be the point in compiling it with tcc? (except for the obvious one of that being an intellectually entertaining experiment) acledit.pEPjUb.s:14: error: unknown assembler directive '.hidden' Okay, so that's supporting (parsing) hidden directive from the assembler itself. While fixing this is easy, you'll hit many more roadblocks in actually compiling real assembler sources (the above seems to be something emitted by the ../../tools/winegcc/winegcc wrapper). TCCs included assembler really isn't much GAS compatible and misses many more directives. /* return a global symbol declaration for an assembly symbol */ const char *asm_globl( const char *func ) default: buffer = strmake( \t.globl %s\n\t.hidden %s\n%s:, func, func, func ); is there any plan for supporting this? There are multiple aspects for supporting hidden symbols: 1) parsing the above (inline) assembler directives. 2) parsing hidden symbols via gcc-compatible visibility attribute. 3) supporting hidden symbol in the builtin link editor. I've done 1) and 2) in the mob branch (e69c506). For 3) there's some code that isn't fully working yet. For x86-64 I've at least implemented correct resolutions of calls to hidden functions. I haven't yet implemented the other archs or correctly handling hidden data symbols. The latter will simply be emitted as non-hidden global symbols (even if they were hidden in the input .o files) right now. grischka: the PE port uses the st_other member of ELF symbols for tracking its own IMPORT/EXPORT directives. As I'm now using it for symbol visibility (with values 0-3) this might clash: using visibility attribute might overwrite former IMPORT/EXPORT directives, and using IMPORT/EXPORT might influence the ELF linker (as it will now make more use of visibility). I lack the necessary pieces to check on windows. If there's indeed an interaction (I can't quite figure that out from just reading the code) but the PE port wants to continue using the st_other member (and not the TCC symbols type) I would guess it's best to use bits outside of mask ELFXX_ST_VISIBILITY (0x3). The COFF port (used for C67) is now a bit more broken than before. It uses st_other for debug type info (ugh!). Is anyone even working on that? Time to remove it maybe? Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Support for hidden symbols?
On Sun, Apr 13, 2014 at 8:22 PM, Michael Matz matz@frakked.de wrote: Hi, On Sat, 12 Apr 2014, Austin English wrote: I recently revisited compiling Wine with TinyCC. I've got some patches for wine for that, but my current blocker is a lack of support for hidden symbols on tcc: Even with that fixed I'll predict some more blockers for wine. It's not exactly one of the most trivial (and C conformant) program packages. And well, wine has some quite performance critical components, so what would be the point in compiling it with tcc? (except for the obvious one of that being an intellectually entertaining experiment) acledit.pEPjUb.s:14: error: unknown assembler directive '.hidden' Okay, so that's supporting (parsing) hidden directive from the assembler itself. While fixing this is easy, you'll hit many more roadblocks in actually compiling real assembler sources (the above seems to be something emitted by the ../../tools/winegcc/winegcc wrapper). TCCs included assembler really isn't much GAS compatible and misses many more directives. /* return a global symbol declaration for an assembly symbol */ const char *asm_globl( const char *func ) default: buffer = strmake( \t.globl %s\n\t.hidden %s\n%s:, func, func, func ); is there any plan for supporting this? There are multiple aspects for supporting hidden symbols: 1) parsing the above (inline) assembler directives. 2) parsing hidden symbols via gcc-compatible visibility attribute. 3) supporting hidden symbol in the builtin link editor. I've done 1) and 2) in the mob branch (e69c506). For 3) there's some code that isn't fully working yet. For x86-64 I've at least implemented correct resolutions of calls to hidden functions. I haven't yet implemented the other archs or correctly handling hidden data symbols. The latter will simply be emitted as non-hidden global symbols (even if they were hidden in the input .o files) right now. grischka: the PE port uses the st_other member of ELF symbols for tracking its own IMPORT/EXPORT directives. As I'm now using it for symbol visibility (with values 0-3) this might clash: using visibility attribute might overwrite former IMPORT/EXPORT directives, and using IMPORT/EXPORT might influence the ELF linker (as it will now make more use of visibility). I lack the necessary pieces to check on windows. If there's indeed an interaction (I can't quite figure that out from just reading the code) but the PE port wants to continue using the st_other member (and not the TCC symbols type) I would guess it's best to use bits outside of mask ELFXX_ST_VISIBILITY (0x3). The COFF port (used for C67) is now a bit more broken than before. It uses st_other for debug type info (ugh!). Is anyone even working on that? Time to remove it maybe? Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel I expected that wine wouldn't immediately work, I'm doing it for the curiosity factor. The next problem is: make[1]: Entering directory `/home/austin/src/wine-tcc/dlls/acledit' /home/austin/tcc/bin/i386-linux-gnu-tcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -g -o main.o main.c ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -shared ./acledit.spec main.o -o acledit.dll.so ../../libs/port/libwine_port.a acledit.UgAqPb.s:14: error: unknown assembler directive '.L__wine_spec_rva_base' winebuild: /home/austin/tcc/bin/i386-linux-gnu-tcc failed with status 1 winegcc: ../../tools/winebuild/winebuild failed make[1]: *** [acledit.dll.so] Error 2 -- -Austin ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
