Strip IR after front-end steps are done (#1092)

* Strip IR after front-end steps are done

The main feature of this change is to unconditonally strip out the `IRHighLevelDeclDecoration`s in an IR module once the "mandatory" IR passes in the front end have run. This ensures that later IR passes (e.g., code emission) *cannot* rely on AST-level information to get their job done.

Since I was already writing a pass to remove some instructions at the end of the front-end passes, I went ahead and also made the `-obfuscate` flag apply to the front-end IR generation by causing it to strip `IRNameHintDecoration`s while it is doing the other stripping. With this, the main identifying information left in IR modules (other than semantics and entry-point names) is mangled name strings for imported/exported symbols.

A few other things got changes along the way:

* Removed the `.expected` file for one of the tests, where that file seemingly shouldn't have been checked in at all.

* Updated the signature of the DCE pass both so that it doesn't require a back-end compile request (it wasn't using it anyway), and so that it takes some options to decide whether to keep symbols marked `[export(...)]` alive (the front-end wants to keep these, while back-end passes currently need to be able to eliminate them).

* Moved the `obfuscateCode` flag from the back-end compile request to the base class shared between front- and back-end requests, and updated the options and repro logic to set both as needed. An obvious improvement in the future would be to have the front- and back-end requests share these settings by referencing a single common object in the end-to-end case, rather than each having their own copy.

* Removed logic that was keeping layout instructions alive in DCE, even if they weren't used. This seems to have been a vestige of an intermediate step between AST and IR layout.

* fixup: add the new files

1 files changed, 20 insertions, 14 deletions

diff --git a/source/slang/slang-ir-dce.cpp b/source/slang/slang-ir-dce.cpp
index 4d58947d4..4359e7e92 100644
--- a/source/slang/slang-ir-dce.cpp
+++ b/source/slang/slang-ir-dce.cpp
@@ -16,8 +16,8 @@ struct DeadCodeEliminationContext
     // the parameters that were passed to the top-level
     // `eliminateDeadCode` function.
     //
-    BackEndCompileRequest*  compileRequest;
-    IRModule*               module;
+    IRModule*                       module;
+    IRDeadCodeEliminationOptions    options;
 
     // Our overall process is going to be to determine
     // which instructions in the module are "live"
@@ -222,11 +222,6 @@ struct DeadCodeEliminationContext
         //
         if(inst->mightHaveSideEffects())
             return true;
-
-        // If it's a layout instruction we don't want to remove it
-        if (as<IRLayout>(inst))
-            return true;
-
         //
         // The `mightHaveSideEffects` query is conservative, and will
         // return `true` as its default mode, so once we are past that
@@ -245,10 +240,21 @@ struct DeadCodeEliminationContext
         if(inst->findDecorationImpl(kIROp_KeepAliveDecoration))
             return true;
         //
-        // TODO: Eventually it would make sense to consider everything
-        // with an `[export(...)]` decoration as live, but our current
-        // approach to linking for back-end compilation leaves many
-        // linkage decorations in place that we seemingly don't need/want.
+        // We also consider anything with an `[export(...)]` as live,
+        // when the appropriate option has been set.
+        //
+        // Note: our current approach to linking for back-end compilation
+        // leaves many linakge decorations in place that we seemingly
+        // don't need/want, so this option currently can't be enabled
+        // unconditionally.
+        //
+        if( options.keepExportsAlive )
+        {
+            if( inst->findDecoration<IRExportDecoration>() )
+            {
+                return true;
+            }
+        }
 
         // A basic block is an interesting case. Knowing that a function
         // is live means that its entry block is live, but the liveness
@@ -317,12 +323,12 @@ struct DeadCodeEliminationContext
 // and then defer to it for the real work.
 //
 void eliminateDeadCode(
-    BackEndCompileRequest* compileRequest,
-    IRModule*       module)
+    IRModule*                           module,
+    IRDeadCodeEliminationOptions const& options)
 {
     DeadCodeEliminationContext context;
-    context.compileRequest = compileRequest;
     context.module = module;
+    context.options = options;
 
     context.processModule();
 }