Hi,

On Fri, 19 Jul 2019 16:32:21 +0300 (MSK)
Alexander Monakov <amona...@ispras.ru> wrote:

> On Fri, 19 Jul 2019, Jozef Lawrynowicz wrote:
> 
> > 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.  
> 
> But ICF by creating an alias would be fine, correct?  As I understand, the
> real issue here is that gcc does not know how to correctly emit a call to
> "interrupt" functions (because they have unusual ABI and exist basically to
> have their address stored somewhere).

Yes I presume in most cases an alias would be ok. It's just that users
sometimes do funky things with interrupt functions to achieve the best possible
performance for their programs, so I wouldn't want to rule out that identical
interrupts may need distinct addresses in some situations. I cannot think of a
use case for that right now though.

So having the option to disable it somehow would be desirable.

> 
> So I think the solution shouldn't be in disabling ICF altogether, but rather
> in adding a way to recognize that a function has quasi-unknown ABI and thus
> not directly callable (so any other optimization can see that it may not emit
> a call to this function), then teaching ICF to check that when deciding to
> fold by creating a wrapper.

I agree, this is a nice suggestion. "call" instructions should be not be
allowed to be generated at all for MSP430 (and whichever other targets)
interrupt functions. Whether that be coming from the user explicitly calling the
interrupt from their code, or GCC generating the call.

This would have to be caught at the point that an optimization pass
first considers inserting a CALL to the interrupt, i.e., if the machine
description tries to prevent the generation of a call to an interrupt function
once the RTL has been generated (e.g. by blanking on the define_expand for
"call"), we are going to have ICEs/wrong code generated a lot of the time.
Particularly in the case originally mentioned here - there would be an empty
interrupt function.

> 
> (would it be possible to tell ICF that addresses of interrupt functions are
> not significant so it can fold them by creating aliases?)

I'll take a look.

Thanks,
Jozef


> 
> Alexander

Reply via email to