brunodf-snps wrote: > We need documentation for the exact assumptions we're making here.
Sure, we can try to work on this (and your other remarks). But what do you have in mind? Since this form of inline assembly is a gcc extension, I consider the gcc documentation and implementation authoritative. But it will not specify the effects of constraints, qualifiers, etc. in the terminology of the LLVM language. The possible and impossible optimizations described in gcc documentation, or the optimizations observed in the gcc implementation, need to be translated to LLVM attributes. > Distinguishing between "volatile" and a "memory clobber" seems a bit > aggressive... I mean, I'm not sure what gcc does here, but it seems like an > extremely subtle distinction. "Volatile" and "memory" clobbers are different concepts for gcc: - https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile-1 "GCC’s optimizers sometimes discard asm statements if they determine there is no need for the output variables. Also, the optimizers may move code out of loops if they believe that the code will always return the same result (i.e. none of its input values change between calls). Using the volatile qualifier disables these optimizations." - https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers-1 : "The "memory" clobber tells the compiler that the assembly code performs memory reads or writes to items other than those listed in the input and output operands (for example, accessing the memory pointed to by one of the input parameters). [...] Using the "memory" clobber effectively forms a read/write memory barrier for the compiler." > Same with marking outputs "mod". Do you mean as opposed to marking them ModRef? https://github.com/llvm/llvm-project/pull/110510 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
