[Catching up after being away, sorry if this has already been resolved.] Jozef Lawrynowicz <joze...@mittosystems.com> writes: > For MSP430, the folding of identical functions marked with the "interrupt" > attribute by -fipa-icf-functions results in wrong code being generated. > Interrupts have different calling conventions than regular functions, so > inserting a CALL from one identical interrupt to another is not correct and > will result in stack corruption. > > I imagine there are other targets that also have different calling conventions > for interrupt functions compared to regular functions, and so folding them > would be undesirable. > > Therefore, I would appreciate some feedback as to whether it would be welcomed > to fix this in a generic way or if I should just keep it MSP430 specific. > > 1. MSP430 specific > Add the "no_icf" attribute to functions marked with the "interrupt" attribute > when processing them in the backend. > > 2. Target Hook > Add a DEFHOOKPOD (e.g. TARGET_NO_INTERRUPT_ICF) which controls whether ICF is > disabled for functions with the interrupt attribute (in gcc/ipa-icf.c, where > "no_icf" attribute is processed).
This sounds like it should be a question about two functions rather than one, i.e.: can functions A and B be merged together if they appear to be identical at some level? I think for most targets, merging two identical interrupt functions would be OK. It's merging an interrupt and non-interrupt function that's the problem. So maybe we need something like targetm.can_inline_p, but for merging rather than inlining? The function would need to be transitive of course. Thanks, Richard > 3. Always on > Same as 2. but without the hook implementation - just check for the interrupt > attribute and disable ICF if it is present. > > I'm personally leaning towards option 2, target hook, since other targets may > benefit from this. > > Thanks, > Jozef
