This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: failed attempt: retain identifier length from frontend to backend


On Mon, Aug 20, 2012 at 7:03 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
> Hello,
>
> my last attempt on improving something serious was about three weeks ago,
> trying to keep all lengths of all strings parsed in the frontend for the
> whole compilation phase until the assembly output. I was hoping that would
> help on using faster hashes (knowing the length allows us to hash 4 or 8
> bytes per iteration), quicker strcmp in various places, and using less
> strlen() calls, which show especially on -g3 compilations that store huge
> macro strings.
>
> I'll post no patch here, since what I currently have is a mess in 3
> different branches and most don't even compile. I tried various approaches.
> First I tried adding an extra length parameter in all relevant functions,
> starting from the assembly generation and working my way upwards. This got
> too complex, and I'd really like to ask if you find any meaning in changing
> target specific hooks and macros to actually accept length as argument (e.g.
> ASM_OUTPUT_*) or return it (e.g. ASM_GENERATE_*). Changes seemed too
> intrusive for me to continue.
>
> But seeing that identifier length is there inside struct ht_identifier (or
> cpp_hashnode) and not lost, I tried the approach of having the length at
> str[-4] for all identifiers. To achieve this I changed ht_identifier to
> store str with the flexible array hack. Unfortunately I hadn't noticed that
> ht_identifier was a part of tree_node and also part of too many other
> structs, so changing all those structs to have variable size was not without
> side effects. In the end it compiled but I got crashes all over, and I'm
> sure I didn't do things right since I broke things like the static assert in
> libcpp/identifiers.c, that I don't even understand:
>
>  /* We don't need a proxy since the hash table's identifier comes first
>     in cpp_hashnode.  However, in case this is ever changed, we have a
>     static assertion for it.  */
> -extern char proxy_assertion_broken[offsetof (struct cpp_hashnode, ident) ==
> 0 ? 1 : -1];
>
> Anyway last attempt was to decouple ht_identifier completely from trees and
> other structs by storing pointer to it, but I was pretty worn out and
> quickly gave up after getting errors on gengtype-generated files that I
> didn't even know how to handle.
>
> Was all this project too ambitious? I'd appreciate all input.

I think the proper thing would indeed have been to pass down the length of
the string to relevant functions.

Richard.

>
> Thanks,
> Dimitris
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]