Mikhail Maltsev <malts...@gmail.com> writes: > On 10.06.2015 10:05, Richard Sandiford wrote: >>> +/* Structure which holds data, required for generating stub gen_* >>> function. */ >> >> No comma after "data" >> >>> +/* These instructions require default stub function. Stubs are never >>> called. >> >> "require a default" >> > [snip] >> Seems like this is more naturally a hash_table rather than a hash_map. >> I think there's also a preference to avoid static constructor-based >> initialisation. > Fixed. > >> There again, this is a generator, so those kinds of concerns aren't >> particularly important. If we do keep the above though, I think we >> should put the hasher in hash-map-table.h now. Otherwise these FIXMEs >> are just going to accumulate, and each time makes it less likely that >> any consolidation will actually happen. > Well, after changing hash_map to hash_table, the hasher class is no > longer identical to other hash traits classes. As for fixing other > occurrences, I think I'd better leave it for another patch.
There are other hash_table string traits though. E.g. config/i386/winnt.c and java/jcf-io.c. Let's not add any more. FWIW I have some patches to try to clean up the hashing traits. I hope to post them later today. Also, sorry for the runaround, but it occured to me later that if we're getting the generators to help us with the default definitions, we might as well go one step further and move the HAVE_foo/gen_foo interface to the target structure, with the structure initialiser being filled in by the generators. I.e. rather than generating a default HAVE_foo and dummy gen_foo, we generate definitions for TARGET_HAVE_FOO and TARGET_GEN_FOO. This should remove the insn-flags.h dependency from most of the target-independent code. There'd be a .def file to list the instructions involved in the HAVE/GEN interface. I have a patch, but also needed a string hash, so ended up spending rather too long on that instead. Hope to post it when the hashing stuff is done. Thanks, Richard
