RE: [PATCH] Implement ‘optnone’ attribute semantics

[Robinson, Paul]

I think taking out the TargetOptions piece mostly wouldn’t interfere with the basic use-case, which is to make debugging easy. It does mean fiddling with how FastISel is enabled, so in SelectionDAGISel::SelectAllBasicBlocks we’d do something like change


if (TM.Options.EnableFastISel)

   FastIS = ...
to

if (TM.Options.EnableFastISel || Fn.hasFnAttribute(Attribute::OptimizeNone))

  FastIS = ...

If we still reset the OptLevel to 0 then when FastISel bails out, regular ISel shouldn’t get too ambitious.
Does that seem reasonable?  I’ll post a revised patch in a bit that does this.  Also the early-exit tweak.
Thanks,
--paulr

From: Bill Wendling [mailto:isanbard at gmail.com]
Sent: Monday, November 18, 2013 12:18 AM
To: Robinson, Paul
Cc: llvm-commits at cs.uiuc.edu commits (llvm-commits at cs.uiuc.edu)
Subject: Re: [PATCH] Implement ‘optnone’ attribute semantics

On Nov 13, 2013, at 4:09 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:


I am energized by positive discussions of the 'optnone' attribute
during the dev meeting last week, so here we go.

Some time ago Andrea Di Biagio committed a patch to define an 'optnone'
attribute in the LLVM IR; he has since passed the torch to me on this
one, so I'm attaching 3 patches to implement the semantics we want.

While the patches all address semantics of 'optnone' I should point
out that (I'm pretty sure) they are independent of each other and
don't have to be reviewed sequentially, or anything like that.

Patch #3 deals with the codegen stuff.  Basically, an 'optnone'
function will be treated as if it were compiled at -O0; this is a
little easier to accomplish than it is for IR-level passes.
You changes in Patch #3 won’t work. You’re changing the TargetOptions settings, but that violates what the back-end is expecting. For instance, the UnsafeFPMath is used during the creation of the back-end to register which actions to perform for which operations. E.g., in X86ISelLowering.cpp X86TargetLowering::resetOperationActions():

    if (!TM.Options.UnsafeFPMath) {
      setOperationAction(ISD::FSIN   , MVT::f64, Expand);
      setOperationAction(ISD::FCOS   , MVT::f64, Expand);
      setOperationAction(ISD::FSINCOS, MVT::f64, Expand);
    }

Is it possible to do FastISel only as an initial stage?

Also, use early exits whenever possible. E.g., this

+    ~OptLevelChanger() {
+      if (IS.OptLevel != SavedOptLevel) {
+        DEBUG(dbgs() << "\nRestoring optimization level for Function "
+              << IS.MF->getFunction()->getName() << "\n");
+        DEBUG(dbgs() << "\tBefore: -O" << IS.OptLevel
+              << " ; After: -O" << SavedOptLevel << "\n");
+        IS.OptLevel = SavedOptLevel;
+        IS.TM.setOptLevel(SavedOptLevel);
+      }
+    }

could be this:

+    ~OptLevelChanger() {
+      if (IS.OptLevel == SavedOptLevel)
+        return
+      DEBUG(dbgs() << "\nRestoring optimization level for Function "
+            << IS.MF->getFunction()->getName() << "\n");
+      DEBUG(dbgs() << "\tBefore: -O" << IS.OptLevel
+            << " ; After: -O" << SavedOptLevel << "\n");
+      IS.OptLevel = SavedOptLevel;
+      IS.TM.setOptLevel(SavedOptLevel);
+    }

-bw

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131118/7066f923/attachment.html>