[PATCH] Inserting directives directly after inline asm blocks

Jack Carter Jack.Carter at imgtec.com
Wed Apr 24 18:18:39 PDT 2013


I am resubmitting the revised patch based on Richard's suggestions.

May I check it in ;-)

Jack
________________________________________
From: Richard Sandiford [rsandifo at linux.vnet.ibm.com]
Sent: Tuesday, April 23, 2013 4:14 AM
To: Jack Carter
Cc: Eric Christopher; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] Inserting directives directly after inline asm blocks

Jack Carter <Jack.Carter at imgtec.com> writes:
> I am going to pull this patch request. We may have to mimic GCC in the
> end due to historical customer code expectations.

Well, like you say, the interface is that asms start in ".set macro;
.set reorder" mode.  But I don't think it should matter whether you
do that by mimicing GCC (i.e. output functions that have asms in
reorder mode, and only wrap specific sequences in noreorder)
or whether you instead change the patch to:

void MipsAsmPrinter::EmitInlineAsm(const MachineInstr *MI) const {
  if (OutStreamer.hasRawTextSupport())
    if (!Subtarget->inMips16Mode())
      OutStreamer.EmitRawText(StringRef("\t.set\treorder"));
  AsmPrinter::EmitInlineAsm(MI);
  if (OutStreamer.hasRawTextSupport())
    if (!Subtarget->inMips16Mode())
      OutStreamer.EmitRawText(StringRef("\t.set\tnoreorder"));
}

GCC does it the way it does because there are other situations
in which functions must be reorder by default.  This includes
various -mfix- options, where the fixes are handled by the assembler,
and the legacy -mno-explicit-relocs mode.  It was just easier to
support only two modes -- the entire function being noreorder,
or the function being reorder with local noreorder spots --
rather than add a third (entire function being noreorder,
except for asms).

Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug916.patch
Type: text/x-patch
Size: 5120 bytes
Desc: bug916.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130425/2c01c950/attachment.bin>


More information about the llvm-commits mailing list