The X86 backend produces an uncompilable .s file for the following function:

---
void %byte() {
  ret void
}
---

The problem is that we currently use .intel_syntax, and gas seems to be broken
in this case.

-Chris

So shall I start hacking on a X86ATTSyntaxPrinter? it seems like the most
bulletproof way to go. We don't need to ditch the existing intel printer; we
might want to use it for debug output or for future work on systems with real
intel-syntax compatible assemblers.

Unfortunately I think that's the best way to go.  Would it be possible to just
parameterize the current asmprinter, like we do for %'s on registers?

-Chris

I was thinking about this, and it occurred to me that we'll need a separate
table of instruction names -- many instructions have different names in AT&T
syntax than they do in Intel syntax.  I don't know if there is a good, non-hacky
way to do this.  We can get pretty far using the "mode suffix" whereby "DWORD
PTR" becomes an "l" at the end of the opcode name, but I distinctly recall
coming across problems in my initial work on the X86 LLC that suggested to me
that there were lots of special cases.

We could easily add the 'at&t' name of each instruction to the X86InstrInfo.td
file, but this is annoying and gross.  :(

-Chris

You could say it comes down to which kind of annoying and gross do we want to
be -- if we expect the 
AT&T syntax to be the special case, Intel syntax can be a hack; if we expect
the Intel syntax to be the 
special case, AT&T syntax can be a hack.

Perhaps we should use AT&T-syntax names in the general case, on the assumption
that most of our 
users will be on Unix or Linux, and have the Intel printer employ a separate
table on the side. I don't 
know  if there are other cases where we are going to need to support multiple
assembly formats, but I 
doubt it, and so I don't necessarily think that we should look for a general
solution to this problem.

I _really_ detest the AT&T style syntax for X86 assembly language.  That said,
it really doesn't matter what I like or don't like.  :)

Here are some observations:
1. Having size suffixes on instructions is occasionally quite useful.  For
   example, what exactly does this do:  %reg1024 = add %reg1026, %reg1028"?
   If it was an 'addl' you would know it's a 32-bit add.
2. GAS is buggy, period.  Until we have our own .o file writer, we will have
   to use it, and we don't want to require the latest and greatest binutils to
   use LLVM.  As such, I think we should definitely be generating AT&T style
   output on unixy systems.
3. We really need to keep support for intel output for support with
   MASM/TASM/etc on the windows side of things.  Especially given your latest
   successes with cygwin, we don't want to discard what we have there.
4. Most AT&T style opcodes are the same as the intel ones, they just have a
   [bwl] suffix on them.

Given all of this stuff.  How about we try this: the opcode names in the
instruction descriptions shall be the AT&T style names.  This makes #1 & #2
happy.  To emit intel style .s files to satisfy #3, we can default to taking the
AT&T opcode, stripping off the suffix letter (ie, take off the last letter if
it's a [bwl]), and printing the result.  I expect this to work for 90% or more
of the instruction opcodes.

If there are cases that don't fit this mold, we can have a little table that
handles them specifically for the intel printer, indicating what they map to. 
The output style will obviously be controlled by a flag, so I can view the
pretty intel syntax when I'm debugging the code generator.  :)

What do you think?

-Chris

I think your plan sounds reasonable. I had to shorten your summary, though. :-)

I like the new subject line :)

-Chris

Note: This is related to:
    http://sources.redhat.com/bugzilla/show_bug.cgi?id=37

Not only are we going to have to do a real AT&T syntax GAS AsmWriter, but we're
going to have to 
make many (albeit trivial, I think) modifications to the Intel syntax AsmWriter
 to get the output to 
assemble with MASM, for example. That, however, is a discussion for another
bug.

I do not expect that I will be able to work on this bug in the near future.
Sorry!

This bug was fixed when we got support for AT&T style asm syntax.

-Chris