Georg-Johann Lay <a...@gjlay.de> writes: > Am 06.12.24 um 13:23 schrieb Sam James: >> Georg-Johann Lay <a...@gjlay.de> writes: >> >>> This patch disables CRC lookup tables which consume quite some RAM. >> Given that -foptimize-crc is new, it may be useful to CC the pass >> authors in case they have input. > > CCing Mariam Arutunian > >>> Ok for trunk? >>> >>> Johann > > The problem is not in the new CRC pass, but because AVR is a very > limited hardware. Because AVR has no linear address space, .rodata > has to be placed in RAM, and most devices have just a few KiB of RAM, > or even less.
(To be clear, I do accept that -- it's more that it's: a) useful as a heads-up to people; b) might affect their future testing; c) might mean we end up talking about whether the patch has issues on other targets). > > An extension PR49857 to put such lookup tables in flash / program memory > has been rejected by the global maintainers as "too specific", ignoring > most of the constraints imposed by the requirement of using named > address-spaces. > > The point is that you cannot just put data in flash, one must also use > the correct instructions to access them, which is achieved by means > of avr specific named address-spaces like __flash. > > This would require a new target hook like proposed in PR49857, which > could put lookup-tables into a non-generic address-space provided: > > *) All respective data is put in the preferred address-space, and > > *) All accesses have to use the same address-space as of 1), > independent of what the rest of the code may look like. > > To date, only 3 lookup tables generated by GCC meet these criteria: > > 1) Lookup tables from tree-switch conversion. > > 2) Lookup tables from the current CRC work > > 3) vtables. Though g++ does not, and probably never will, support > named address spaces. Thanks for the extra context! > > Johann sam
