[PATCH] D99708: [X86] Enable compilation of user interrupt handlers.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D99708#2664351 <https://reviews.llvm.org/D99708#2664351>, @hjl.tools wrote:

> In D99708#2664218 <https://reviews.llvm.org/D99708#2664218>, @craig.topper wrote:
>
>> In D99708#2664164 <https://reviews.llvm.org/D99708#2664164>, @hjl.tools wrote:
>>
>>> In D99708#2664076 <https://reviews.llvm.org/D99708#2664076>, @LuoYuanke wrote:
>>>
>>>> In D99708#2663989 <https://reviews.llvm.org/D99708#2663989>, @craig.topper wrote:
>>>>
>>>>> A user interrupt is different than a regular interrupt right? It doesn't make sense that we would change the behavior of the interrupt calling convention just because the the user interrupt instructions are enabled. That would occur just from passing a -march for a newer CPU wouldn't it?
>>>>
>>>> Maybe need support another attribute "__attribute__ ((user_interrupt))" for functions? However this is what gcc does (https://gcc.godbolt.org/z/8ojTMG6bT).
>>>
>>> Since there won't be both user interrupt handler and kernel interrupt handler in the source, there is no need for another
>>> attribute.   We discussed that kernel might need to use UINTR instructions.  We decided that kernel could use inline asm
>>> statements if needed.
>>
>> So if write kernel code and compile with -march=haswell today, I get IRET. If tomorrow I change my command line to -march=sapphirerapids, now my kernel interrupt code generates user interrupt instructions. That seems surprising.
>
> -mcmodel=kernel should disable uiret.:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99870

That makes sense. Can we put that in this patch?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99708/new/

https://reviews.llvm.org/D99708