Certain sub-PAC crates build slowly

[mciantyre]

cargo +nightly build --release -Z timings

reveals that the top 5 slowest crates to compile are...

	Unit	Total	Codegen	Features
1.	imxrt1062-iomuxc v0.1.0	70.5s	4.7s (7%)
2.	imxrt1062-can3 v0.1.0	69.7s	0.5s (1%)
3.	imxrt1062-dma0 v0.1.0	39.1s	3.7s (9%)
4.	syn v1.0.14	36.3s	28.0s (77%)	clone-impls, default, derive, extra-traits, full, parsing, printing, proc-macro, quote
5.	cc v1.0.50	16.1s	15.2s (94%)

Total time: 83.8s (1m 23.8s)
rustc: rustc 1.43.0-nightly (58b834344 2020-02-05)
Host: x86_64-apple-darwin
Target: thumbv7em-none-eabihf

The iomuxc, can3, and dma0 sub-PACs are auto-generated from the processor SVD. There may be opportunities to reduce the amount of auto-generated code. It might lead to both faster builds and simpler PAC APIs.

Propose changes to the SVD so that the three sub-PACs compile faster. Ideally, they also export a simpler API.

[mciantyre]

We're considering using DMA as part of #47, so it might make sense to tackle that crate first.

[mciantyre]

The iomuxc crate API is already used in the HAL. Changes to that sub-PAC will require us to update the HAL. I'm not worried about maintaining backwards-compatibility.

I'm also OK with exposing an unsafe IOMUXC API. Without looking deeply at the SVD, I'm betting that each MUX register is unique, because each MUX register supports a specific set of alternatives. If we were to relax that by requiring unsafe writes and reads to alt fields, we might simplify the PAC API. Then, we could add the safety in the HAL using our pad! macros..

A hypothetical IOMUXC RegisterBlock could resemble

#[repr(C)]
pub struct RegisterBlock {
  sw_mux_ctl_pad_gpio_emc: [SW_MUX_CTL_PAD_GPIO_EMC; 42],
  sw_mux_ctl_pad_gpio_ad_b0: [SW_MUX_CTL_PAD_GPIO_AD_B0; 16],
  // Other SW_MUX_CTL registers...

  sw_pad_ctl_pad_gpio_emc: [SW_PAD_CTL_PAD_GPIO_EMC; 42],
  sw_pad_ctl_pad_gpio_ad_b0: [SW_PAD_CTL_PAD_GPIO_AD_B0; 16],
  // Other SW_PAD_CTL registers...
}

which reduces the plurality of MUX and PAD control registers. We could even simplify this further, by defining a single SW_MUX_CTL_PAD_GPIO type and SW_PAD_CTL_PAD_GPIO type for MUX and PAD control, respectively. (There are still other things that need to be evaluated, like DAISY registers, that might affect these ideas.)

Might affect #46.

[jonas-schievink]

Just to clarify (as someone who isn't using these crates actively at the moment), do the graphs above mean that rustc takes over a minute to build a PAC for a single peripheral?

[mciantyre]

That's right.

If we take the stock iMXRT1062 SVD file and pass it through svd2rust, the crate takes many minutes to build. I haven't recently measured it on my machine, but I also had very long build times.

Separating each peripheral into its own crate helps. But yes, some peripherals are still taking over a minute to build. The approach proposed here is to clean-up the SVD so that svd2rust doesn't generate as much code. 6ccbf80 is an example of that effort.

#49 describes an approach that removes the svd2rust-generated crates. We instead use a different auto-generated crate that builds much faster. I'll be working on a port of the HAL to take advantage of this approach.

[mciantyre]

Closing. Users should favor the imxrt-ral.