https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120019
--- Comment #4 from Rainer Orth <ro at gcc dot gnu.org> --- (In reply to Uroš Bizjak from comment #3) > (In reply to Uroš Bizjak from comment #2) > > > Please detect support during configure time and create an operand modifier > > that will output "gs " or "fs " for non-default address spaces. Then output > > e.g. "%^%x1rep movsq" for "gs rep movsq" when assembler doesn't support new > > form. > > 'v' is still free for the modifier, you can use this letter to return e.g.: > > "%^%v1rep movsq" > > where %v1 is substituted with either "gs " or "fs " for the memory operand > in the non-default address space (ADDR_SPACE_SEG_GS or ADDR_SPACE_SEG_FS). Thanks, that got me going, although it took me some time to wrap my head around it given no prior backend experience. The attached patch was tested successfully on i386-pc-solaris2.11 (as and gas) and x86_64-pc-linux-gnu. There are a few caveats, though: * I'm not too fond of the MOVS_OPERANDS solution, although it avoids lots of duplication at the use sites. * I wondered about documentation: right now, x86 operand modifiers are documented in up to three places: ** head comment for ix86_print_operand in i386.cc ** head comment in i386.md ** x86 Operand Modifiers section of extend.texi AFAICS, at least in extend.texi several are missing already, so I didn't add 'v' there yet * Overall, I wonder if all this complexity is warranted given the warnings the X86 Instruction Set Reference mentions for the explicit-operands form of movs. Maybe it would be easier to just go with the no-operands form everywhere?
