On 04/14/2014 11:10 PM, Masami Hiramatsu wrote: > (2014/04/15 11:28), Sasha Levin wrote: >> On 04/14/2014 09:41 PM, Masami Hiramatsu wrote: >>> (2014/04/15 2:44), Sasha Levin wrote: >>>>> Right now we generate data for the instruction decoder and place it >>>>> as a code file which gets #included directly (yuck). >>>>> >>>>> Instead, make it a header which will also be usable by other code >>>>> that wants to use the data in there. >>> Hmm, making the generated data into a header file may clone >>> the data table instances for each object file. Since the inat >>> table is not so small, I think we'd better just export the tables. >> >> The tables are defined as static, so the compiler drops them >> once it detects they are not used. > > No, I meant that if the table is used in the different object files, > will the copies of the tables be compiled in several different > instances?
That's true, but there was and after this patchset there will still be only one user that touches the table. I also doubt that more users will appear since users of the table should be going through the API and not touching it directly, so I don't think it should be a concern at this point. > And I can't see the part which makes the tables static in this patch... Right, it sneaked to the next patch in this patchset. I'll pull it into this one in the next version. >> I feel it would be easier to let the compiler do it's job rather >> than do optimizations we don't need to do and which will complicate >> the code quite a bit. > > I haven't tend to optimize it, but just encapsulate it, to hide from other > parts. We could hide it under #ifdef, but that wouldn't change anything for the user or for the generated code itself. Splitting code generation into two different files would complicate everything IMO. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
