ahmedbougacha wrote:

> > * Calling a function marked interrupt from a function marked interrupt is 
> > still UB isn't it? Should there be another warning to cover that scenario 
> > as well?
> 
> Correct. I can create a separate issue to describe such a warning. Calling an 
> interrupt handler from a normal function is also UB for similar reasons; when 
> it returns it will attempt an exception return for an exception that hasn't 
> occurred, so either it's immediately undefined because the caller was already 
> in system/user, or the caller was in supervisor mode from reset, and an 
> exception return will update CPSR to whatever garbage was in SPSR_svc, and 
> also it will return to the calling instruction, rather than one past it.

Catching up with this: as far as I can tell this is true for A/R profiles, but 
M profile doesn't have this restriction, because the exception return sequence 
isn't special.  And the plain return we codegen only behaves as an exception 
return when the LR bits are setup in the special way.  So it can return just 
fine if LR is a regular return address.  I read that as saying there's no 
restriction to calling `interrupt` functions when targeting M profile.  Does 
that sound correct to you all?  Is there another reason to restrict calls even 
for M profile?  (beyond "why would anyone ever do that" ;)

I see you mentioned the related #47815 :
> I'd like to also address https://github.com/llvm/llvm-project/issues/47815, 
> but I wasn't able to find the right path to answer "is this M-profile" from 
> TargetInfo. Would appreciate any suggestions on that. I think it may require 
> dynamic_cast-ing the TargetInfo to an ARMTargetInfo, and then change one of 
> the methods in there to be public...

I think the somewhat-clean way to do that would be to add a bit in `TargetInfo` 
(see e.g., `ARMCDECoprocMask`), initialize it in `ARMTargetInfo` based on 
`ArchProfile == M`, and checking it in Sema via `Context.getTargetInfo()`

https://github.com/llvm/llvm-project/pull/91870
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to