On Mon, Jun 19, 2023 at 05:05:48PM +0800, pan2...@intel.com wrote:
> --- a/gcc/lto-streamer-in.cc
> +++ b/gcc/lto-streamer-in.cc
> @@ -1985,7 +1985,8 @@ lto_input_mode_table (struct lto_file_decl_data
> *file_data)
> internal_error ("cannot read LTO mode table from %s",
> file_data->file_name);
>
> - unsigned char *table = ggc_cleared_vec_alloc<unsigned char> (1 << 8);
> + unsigned char *table = ggc_cleared_vec_alloc<unsigned char> (
> + MAX_MACHINE_MODE);
Incorrect formatting. And, see my other mail, this is wrong.
> @@ -108,7 +108,7 @@ inline void
> bp_pack_machine_mode (struct bitpack_d *bp, machine_mode mode)
> {
> streamer_mode_table[mode] = 1;
> - bp_pack_enum (bp, machine_mode, 1 << 8, mode);
> + bp_pack_enum (bp, machine_mode, MAX_MACHINE_MODE, mode);
> }
>
> inline machine_mode
> @@ -116,7 +116,8 @@ bp_unpack_machine_mode (struct bitpack_d *bp)
> {
> return (machine_mode)
> ((class lto_input_block *)
> - bp->stream)->mode_table[bp_unpack_enum (bp, machine_mode, 1 << 8)];
> + bp->stream)->mode_table[bp_unpack_enum (bp, machine_mode,
> + MAX_MACHINE_MODE)];
> }
And these two are wrong as well. The value passed to bp_pack_enum
has to match the one used on bp_unpack_enum. But that is not the case
after your changes. You stream out with the host MAX_MACHINE_MODE, and
stream in for normal LTO with the same value (ok), but for offloading
targets (nvptx, amdgcn) with a different MAX_MACHINE_MODE. That will
immediate result in LTO streaming being out of sync and ICEs all around.
The reason for using 1 << 8 there was exactly to make it interoperable for
offloading. What could be perhaps done is that you stream out the
host MAX_MACHINE_MODE value somewhere and stream it in inside of
lto_input_mode_table before you allocate the table. But, that streamed
in host max_machine_mdoe has to be remembered somewhere and used e.g. in
bp_unpack_machine_mode instead of MAX_MACHINE_MODE.
Jakub
