[RFC, PowerPC] Always use "assembler dialect" 1

[Hal Finkel]

----- Original Message -----
> 
> Hello,
> 
> a setting in MCAsmInfo defines the "assembler dialect" to use.  This
> is
> used by common code to chose between alternatives in a
> multi-alternative
> GNU inline asm statement like the following:
> 
>   __asm__ ("{sfe|subfe} %0,%1,%2" : "=r" (out) : "r" (in1), "r"
>   (in2));
> 
> The meaning of these dialects is platform specific, and GCC defines
> those
> for PowerPC to use dialect 0 for old-style (POWER) mnemonics and 1
> for
> new-style (PowerPC) mnemonics, like in the example above.   To be
> compatible with inline asm used with GCC, LLVM ought to do the same.
> Specifically, this means we should always use assembler dialect 1
> since
> old-style mnemonics really aren't supported on any current platform
> (as of
> GCC 4.8, GCC also no longer supports old-style mnemonics).
> 
> However, the current LLVM back-end uses:
>   AssemblerDialect = 1;           // New-Style mnemonics.
> in PPCMCAsmInfoDarwin, and
>   AssemblerDialect = 0;           // Old-Style mnemonics.
> in PPCLinuxMCAsmInfo.
> 
> The Linux setting really isn't correct, we should be using new-style
> mnemonics everywhere.
> 
> Unfortunately, the setting of this variable is overloaded in back-end
> to
> decide whether or not we are on a Darwin target by back-end code.
>  This is
> done in PPCInstPrinter (the "SyntaxVariant" is initialized from the
> MCAsmInfo AssemblerDialect setting), and also in PPCMCExpr.  So
> setting
> AssemblerDialect to 1 for both Darwin and Linux no longer allows use
> to
> make this distinction.
> 
> Both PPCInstPrinter and PPCMCExpr have a MCAsmInfo available to
> discriminate between Darwin and Linux, and we do in fact have two
> different
> MCAsmInfo structures allocated on the target.  Unfortunately, we
> cannot
> easily check which of them we got (MCAsmInfo doesn't support isa<>).
>   So
> I've changed those two places to use a different member of MCAsmInfo
> as
> "stand-in" to distinguish between Darwin and non-Darwin:
> hasMachoZeroFillDirective.  Since this is currently on Darwin and
> only on
> Darwin, it works for the purpose, but it seems a bit ugly.
> 
> Any other suggestions are certainly welcome.   Should we maybe extend
> the
> generic MCAsmInfo by a "isDarwin" field?

Of the two, I'd be in favor of adding an isDarwin field, and that will make it clear what is going on. However, is there a reason that we just can't give the printer access to the target triple somehow (either directly, or via a MCSubtargetInfo object, etc.)?

Thanks again,
Hal

> 
> Bye,
> Ulrich
> 
> (See attached file: diff-llvm-asmdialect)

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory