Skip to content

Conversation

@copybara-service
Copy link
Contributor

Rename xnn_init_config to xnn_get_config

I think this both better reflects what these functions are doing, and also solves a minor problem I have: I'm trying to enable stronger testing of the configs, which is most easily implemented by allowing xnn_get_hardware_config's return value to be changed via an xnn_set_hardware_config(...) function. In order to implement this, I'd like to have:

  • xnn_init_hardware_config to return the "real" hardware configuration based on cpuinfo,
  • xnn_get_hardware_config to return the global hardware config (by default, equal to xnn_init_hardware_config,
  • xnn_set_hardware_config, which allows changing the global hardware config.

Renaming is not necessary for this, but I do think it's slightly nicer this way, and I do think xnn_get_*_config is a more appropriate name for the functions we actually have now.

I think this both better reflects what these functions are doing, and also solves a minor problem I have: I'm trying to enable stronger testing of the configs, which is most easily implemented by allowing `xnn_get_hardware_config`'s return value to be changed via an `xnn_set_hardware_config(...)` function. In order to implement this, I'd like to have:
- `xnn_init_hardware_config` to return the "real" hardware configuration based on cpuinfo,
- `xnn_get_hardware_config` to return the global hardware config (by default, equal to `xnn_init_hardware_config`,
- `xnn_set_hardware_config`, which allows changing the global hardware config.

Renaming is not necessary for this, but I do think it's slightly nicer this way, and I do think `xnn_get_*_config` is a more appropriate name for the functions we actually have now.

PiperOrigin-RevId: 772223989
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant