Re: [PATCH 2/4] x86: Move instruction decoder data into header
(2014/04/15 23:24), Sasha Levin wrote: > 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. Agreed, so I don't like to expose it. If no one need them, then give it to the owner. That must be the safest. >> 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. No, mixing data (definitions) and declarations on one header should be avoided, especially that is generated in the build path. I'd like to ask you to split them into header and body. I know it will be harder to implement, but worth to maintain. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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/
Re: [PATCH 2/4] x86: Move instruction decoder data into header
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/
Re: [PATCH 2/4] x86: Move instruction decoder data into header
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/
Re: [PATCH 2/4] x86: Move instruction decoder data into header
(2014/04/15 23:24), Sasha Levin wrote: 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. Agreed, so I don't like to expose it. If no one need them, then give it to the owner. That must be the safest. 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. No, mixing data (definitions) and declarations on one header should be avoided, especially that is generated in the build path. I'd like to ask you to split them into header and body. I know it will be harder to implement, but worth to maintain. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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/
Re: Re: [PATCH 2/4] x86: Move instruction decoder data into header
(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? And I can't see the part which makes the tables static in this patch... > 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. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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/
Re: [PATCH 2/4] x86: Move instruction decoder data into header
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. 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. 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/
Re: [PATCH 2/4] x86: Move instruction decoder data into header
(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. Thank you, > > Signed-off-by: Sasha Levin > --- > arch/x86/Makefile |6 ++ > arch/x86/lib/Makefile |8 +--- > arch/x86/lib/inat.c |2 +- > arch/x86/tools/Makefile |8 > 4 files changed, 16 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index 602f57e..26eee4e 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -178,6 +178,12 @@ archscripts: scripts_basic > $(Q)$(MAKE) $(build)=arch/x86/tools relocs > > ### > +# inat instruction table generation > + > +archprepare: > + $(Q)$(MAKE) $(build)=arch/x86/lib inat_tables > + > +### > # Syscall table generation > > archheaders: > diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile > index eabcb6e..3014da8 100644 > --- a/arch/x86/lib/Makefile > +++ b/arch/x86/lib/Makefile > @@ -7,12 +7,12 @@ inat_tables_maps = > $(srctree)/arch/x86/lib/x86-opcode-map.txt > quiet_cmd_inat_tables = GEN $@ >cmd_inat_tables = $(AWK) -f $(inat_tables_script) $(inat_tables_maps) > > $@ || rm -f $@ > > -$(obj)/inat-tables.c: $(inat_tables_script) $(inat_tables_maps) > +$(obj)/../include/generated/asm/inat-tables.h: $(inat_tables_script) > $(inat_tables_maps) > $(call cmd,inat_tables) > > -$(obj)/inat.o: $(obj)/inat-tables.c > +$(obj)/inat.o: $(obj)/../include/generated/asm/inat-tables.h > > -clean-files := inat-tables.c > +clean-files := ../include/asm/inat-tables.h > > obj-$(CONFIG_SMP) += msr-smp.o cache-smp.o > > @@ -44,3 +44,5 @@ else > lib-y += copy_user_64.o copy_user_nocache_64.o > lib-y += cmpxchg16b_emu.o > endif > + > +inat_tables: $(obj)/../include/generated/asm/inat-tables.h > diff --git a/arch/x86/lib/inat.c b/arch/x86/lib/inat.c > index c1f01a8..641a996 100644 > --- a/arch/x86/lib/inat.c > +++ b/arch/x86/lib/inat.c > @@ -21,7 +21,7 @@ > #include > > /* Attribute tables are generated from opcode map */ > -#include "inat-tables.c" > +#include > > /* Attribute search APIs */ > insn_attr_t inat_get_opcode_attribute(insn_byte_t opcode) > diff --git a/arch/x86/tools/Makefile b/arch/x86/tools/Makefile > index e812034..e34e7e3 100644 > --- a/arch/x86/tools/Makefile > +++ b/arch/x86/tools/Makefile > @@ -28,14 +28,14 @@ posttest: $(obj)/test_get_len vmlinux $(obj)/insn_sanity > hostprogs-y += test_get_len insn_sanity > > # -I needed for generated C source and C source which in the kernel tree. > -HOSTCFLAGS_test_get_len.o := -Wall -I$(objtree)/arch/x86/lib/ > -I$(srctree)/arch/x86/include/uapi/ -I$(srctree)/arch/x86/include/ > -I$(srctree)/arch/x86/lib/ -I$(srctree)/include/uapi/ > +HOSTCFLAGS_test_get_len.o := -Wall -I$(objtree)/arch/x86/lib/ > -I$(srctree)/arch/x86/include/uapi/ -I$(srctree)/arch/x86/include/ > -I$(srctree)/arch/x86/lib/ -I$(srctree)/include/uapi/ > -I$(srctree)/arch/x86/include/generated/ > > -HOSTCFLAGS_insn_sanity.o := -Wall -I$(objtree)/arch/x86/lib/ > -I$(srctree)/arch/x86/include/ -I$(srctree)/arch/x86/lib/ > -I$(srctree)/include/ > +HOSTCFLAGS_insn_sanity.o := -Wall -I$(objtree)/arch/x86/lib/ > -I$(srctree)/arch/x86/include/ -I$(srctree)/arch/x86/lib/ > -I$(srctree)/include/ -I$(srctree)/arch/x86/include/generated/ > > # Dependencies are also needed. > -$(obj)/test_get_len.o: $(srctree)/arch/x86/lib/insn.c > $(srctree)/arch/x86/lib/inat.c $(srctree)/arch/x86/include/asm/inat_types.h > $(srctree)/arch/x86/include/asm/inat.h $(srctree)/arch/x86/include/asm/insn.h > $(objtree)/arch/x86/lib/inat-tables.c > +$(obj)/test_get_len.o: $(srctree)/arch/x86/lib/insn.c > $(srctree)/arch/x86/lib/inat.c $(srctree)/arch/x86/include/asm/inat_types.h > $(srctree)/arch/x86/include/asm/inat.h $(srctree)/arch/x86/include/asm/insn.h > $(objtree)/arch/x86/include/generated/asm/inat-tables.h > > -$(obj)/insn_sanity.o: $(srctree)/arch/x86/lib/insn.c > $(srctree)/arch/x86/lib/inat.c $(srctree)/arch/x86/include/asm/inat_types.h > $(srctree)/arch/x86/include/asm/inat.h $(srctree)/arch/x86/include/asm/insn.h > $(objtree)/arch/x86/lib/inat-tables.c > +$(obj)/insn_sanity.o: $(srctree)/arch/x86/lib/insn.c > $(srctree)/arch/x86/lib/inat.c $(srctree)/arch/x86/include/asm/inat_types.h > $(srctree)/arch/x86/include/asm/inat.h $(srctree)/arch/x86/include/asm/insn.h > $(objtree)/arch/x86/include/generated/asm/inat-tables.h > > HOST_EXTRACFLAGS += -I$(srctree)/tools/include > hostprogs-y += relocs > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory
Re: [PATCH 2/4] x86: Move instruction decoder data into header
(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. Thank you, Signed-off-by: Sasha Levin sasha.le...@oracle.com --- arch/x86/Makefile |6 ++ arch/x86/lib/Makefile |8 +--- arch/x86/lib/inat.c |2 +- arch/x86/tools/Makefile |8 4 files changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 602f57e..26eee4e 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -178,6 +178,12 @@ archscripts: scripts_basic $(Q)$(MAKE) $(build)=arch/x86/tools relocs ### +# inat instruction table generation + +archprepare: + $(Q)$(MAKE) $(build)=arch/x86/lib inat_tables + +### # Syscall table generation archheaders: diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index eabcb6e..3014da8 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -7,12 +7,12 @@ inat_tables_maps = $(srctree)/arch/x86/lib/x86-opcode-map.txt quiet_cmd_inat_tables = GEN $@ cmd_inat_tables = $(AWK) -f $(inat_tables_script) $(inat_tables_maps) $@ || rm -f $@ -$(obj)/inat-tables.c: $(inat_tables_script) $(inat_tables_maps) +$(obj)/../include/generated/asm/inat-tables.h: $(inat_tables_script) $(inat_tables_maps) $(call cmd,inat_tables) -$(obj)/inat.o: $(obj)/inat-tables.c +$(obj)/inat.o: $(obj)/../include/generated/asm/inat-tables.h -clean-files := inat-tables.c +clean-files := ../include/asm/inat-tables.h obj-$(CONFIG_SMP) += msr-smp.o cache-smp.o @@ -44,3 +44,5 @@ else lib-y += copy_user_64.o copy_user_nocache_64.o lib-y += cmpxchg16b_emu.o endif + +inat_tables: $(obj)/../include/generated/asm/inat-tables.h diff --git a/arch/x86/lib/inat.c b/arch/x86/lib/inat.c index c1f01a8..641a996 100644 --- a/arch/x86/lib/inat.c +++ b/arch/x86/lib/inat.c @@ -21,7 +21,7 @@ #include asm/insn.h /* Attribute tables are generated from opcode map */ -#include inat-tables.c +#include asm/inat-tables.h /* Attribute search APIs */ insn_attr_t inat_get_opcode_attribute(insn_byte_t opcode) diff --git a/arch/x86/tools/Makefile b/arch/x86/tools/Makefile index e812034..e34e7e3 100644 --- a/arch/x86/tools/Makefile +++ b/arch/x86/tools/Makefile @@ -28,14 +28,14 @@ posttest: $(obj)/test_get_len vmlinux $(obj)/insn_sanity hostprogs-y += test_get_len insn_sanity # -I needed for generated C source and C source which in the kernel tree. -HOSTCFLAGS_test_get_len.o := -Wall -I$(objtree)/arch/x86/lib/ -I$(srctree)/arch/x86/include/uapi/ -I$(srctree)/arch/x86/include/ -I$(srctree)/arch/x86/lib/ -I$(srctree)/include/uapi/ +HOSTCFLAGS_test_get_len.o := -Wall -I$(objtree)/arch/x86/lib/ -I$(srctree)/arch/x86/include/uapi/ -I$(srctree)/arch/x86/include/ -I$(srctree)/arch/x86/lib/ -I$(srctree)/include/uapi/ -I$(srctree)/arch/x86/include/generated/ -HOSTCFLAGS_insn_sanity.o := -Wall -I$(objtree)/arch/x86/lib/ -I$(srctree)/arch/x86/include/ -I$(srctree)/arch/x86/lib/ -I$(srctree)/include/ +HOSTCFLAGS_insn_sanity.o := -Wall -I$(objtree)/arch/x86/lib/ -I$(srctree)/arch/x86/include/ -I$(srctree)/arch/x86/lib/ -I$(srctree)/include/ -I$(srctree)/arch/x86/include/generated/ # Dependencies are also needed. -$(obj)/test_get_len.o: $(srctree)/arch/x86/lib/insn.c $(srctree)/arch/x86/lib/inat.c $(srctree)/arch/x86/include/asm/inat_types.h $(srctree)/arch/x86/include/asm/inat.h $(srctree)/arch/x86/include/asm/insn.h $(objtree)/arch/x86/lib/inat-tables.c +$(obj)/test_get_len.o: $(srctree)/arch/x86/lib/insn.c $(srctree)/arch/x86/lib/inat.c $(srctree)/arch/x86/include/asm/inat_types.h $(srctree)/arch/x86/include/asm/inat.h $(srctree)/arch/x86/include/asm/insn.h $(objtree)/arch/x86/include/generated/asm/inat-tables.h -$(obj)/insn_sanity.o: $(srctree)/arch/x86/lib/insn.c $(srctree)/arch/x86/lib/inat.c $(srctree)/arch/x86/include/asm/inat_types.h $(srctree)/arch/x86/include/asm/inat.h $(srctree)/arch/x86/include/asm/insn.h $(objtree)/arch/x86/lib/inat-tables.c +$(obj)/insn_sanity.o: $(srctree)/arch/x86/lib/insn.c $(srctree)/arch/x86/lib/inat.c $(srctree)/arch/x86/include/asm/inat_types.h $(srctree)/arch/x86/include/asm/inat.h $(srctree)/arch/x86/include/asm/insn.h $(objtree)/arch/x86/include/generated/asm/inat-tables.h HOST_EXTRACFLAGS += -I$(srctree)/tools/include hostprogs-y += relocs -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this
Re: [PATCH 2/4] x86: Move instruction decoder data into header
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. 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. 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/
Re: Re: [PATCH 2/4] x86: Move instruction decoder data into header
(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? And I can't see the part which makes the tables static in this patch... 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. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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/
