mimxrt1050_evk: build time too long for this platform

Describe the bug
After this PR(#44150) merged, the total build and run time for mimxrt1050_evk has been extended a lot, from approximately 4-5 hours to 7-8 hours.
And found the the biggest change is in the build stage, time cost almost doubled.

To Reproduce
Steps to reproduce the behavior:

1. twister -p mimxrt1050_evk --device-testing --device-serial /dev/ttyACM0 -T tests/ -T samples/ - j 1

Environment (please complete the following information):

• OS: Linux
• Toolchain zephyr-sdk-0.13.2
• Commit 40526f8

Hi @danieldegrasse, any idea on this?

[danieldegrasse]

@LixinGuoX the build time change is introduced by a0a0f65, more than likely because the DTS file generated for the RT1050 EVK, and thus devicetree_unfixed.h grows significantly with the inclusion of all pin control nodes (95320 SLOC on a0a0f65, and 14238 SLOC on 766ef95). The core issue seems to be that all the pin control nodes are now included in the devicetree_unfixed.h header file, which means the C preprocessor has significantly more data to parse. Regenerating the pin control definition with additional unused "dummy" pin control nodes increases the size of devicetree_unfixed.h and also increases the build time significantly.

I'm not sure exactly how to fix this issue, since the iMX RT pinmux controller is complicated enough that the pin mux settings can't be encapsulated by a #define (see here for more details). @mbolivar-nordic do you know how to avoid this impact on build time, or know who I should ask for more advice? I'm not familiar enough with the devicetree generation to know how we could reduce the size of devicetree_unfixed.h, or reduce the impact its length has on build times. To be clear, only a subset of those devicetree nodes for pin control are actually being used, since multiple pin mux options are defined for each physical pin

[nashif]

"-j 1" is really bad, you should try without -j1, not directly related to the issue and commits above, but this will speed up things considerably, i.e. build on process while you are flashing and testing on another.

[nashif]

@gmarull @carlescufi FYI

Without '- j 1' , it can speed up to 90min, will then reset back and see real effect of the patch above.

[gmarull]

That's an interesting case, also thanks for the investigation @danieldegrasse. I think we should probably look at optimizing the contents of devicetree_unfixed.h, since it's included by devicetree.h, a header used in lots of places. May have some relation with #41543.

[danieldegrasse]

@gmarull I think this does relate to #41543. I ran some tests to confirm the issue is related to the length of the header file, and not devicetree itself, by modifying the CMSIS header file for the RT1052 SOC, which should be included in most NXP drivers in Zephyr. The file itself is 52542 SLOC, and building hello_world with a clean cache took me 29.413s on 766ef95. Adding 200k lines of unused defines (of the format #define TEST_VALn n, where n ranges from 0-199,999, increased the build time to 1:00.99. It appears the issue is pretty directly related to the C preprocessor slowing down on large header files.

[mbolivar-nordic]

@danieldegrasse have a look at /omit-if-no-ref/ here: https://elinux.org/Device_Tree_Source_Undocumented and see if adding it to your pinctrl nodes might work for you

[danieldegrasse]

@mbolivar thanks for the hint- build time seems to improve with that change, from 49 to 37 seconds. devicetree_unfixed.h goes from 103959 SLOC to 41148 SLOC. I've opened #44319 to include the new pin control headers, with that property present.