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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
