hjl.tools added a comment. 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 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
