https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120019
--- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Rainer Orth from comment #4) > (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. It is really a nice patch, you included some ideas I didn't consider. Great job! > 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? The solution with explicit operands was intended to *avoid* using new operand modifier, but at the end of the day, it brought more pain than gain. We can achieve the same using explicit addr32 prefix and explicit segment override, as is the case with your patch. So, I agree with you that introducing MOVS_OPERANDS is an overkill. I will comment your attached patch inline. Thanks!
