Remove workaround from #1960

Author: zasdfgbnm

torch/csrc/jit/codegen/cuda/lower_index_compute.cpp

@@ -731,36 +731,8 @@ void LoopIndexingAnalysis::constructLoopDomains() {
               !concrete_id_to_consumer_.count(concrete_id) &&
               // Use permissive map so the selected ID indeed represents the
               // loop.
-              // Note: see PR https://github.com/csarofeen/pytorch/pull/1960
-              //  and issue https://github.com/csarofeen/pytorch/issues/1873
-              // This mapping look up is part of a staged indexing scheme.
-              //  When we find a replayed exact id that exactly map to the loop
-              //  id, this means that we can resolve indexing involved in this
-              //  loop "locally", i.e. only with and with only the iterdomains
-              //  on the
-              //
-              //  given consumer tv.
-              //  When we cannot find an exact mapping, the permissive mapping
-              //  would
-              //   help defering the indexing resolution for this loop nest
-              //   level to other iterdomain expressions from tv's that are
-              //   further concretized and usually they are further down the
-              //   consumer chain of the given consumer tv.
-              //
-              //  Intuitively exact mapping of two iterdomains should imply
-              //  permissive mapping
-              //   of them as well and if that was the case, only looking up
-              //   permissive mapping would be enough to address both of the
-              //   cases above.
-              //  FIXME: But currently exact mapping does not imply permissive
-              //  mapping (See issue:
-              //       https://github.com/csarofeen/pytorch/issues/1963)
-              // Which means we should check both exact and permissive mapping
-              // here.
-              (GpuLower::current()->caMap()->areMapped(
-                   concrete_id, loop_id, IdMappingMode::EXACT) ||
-               GpuLower::current()->caMap()->areMapped(
-                   concrete_id, loop_id, IdMappingMode::PERMISSIVE));
+              GpuLower::current()->caMap()->areMapped(
+                  concrete_id, loop_id, IdMappingMode::PERMISSIVE);
         });
 
     TORCH_INTERNAL_ASSERT(

torch/csrc/jit/codegen/cuda/test/test_gpu3.cpp

@@ -6157,6 +6157,8 @@ TEST_F(NVFuserTest, FusionEmpty_CUDA) {
 }
 
 TEST_F(NVFuserTest, FusionMappingRelation_CUDA) {
+  // See https://github.com/csarofeen/pytorch/pull/1960
+  // and
   std::unique_ptr<Fusion> fusion_ptr = std::make_unique<Fusion>();
   auto fusion = fusion_ptr.get();
   FusionGuard fg(fusion);
@@ -6179,13 +6181,10 @@ TEST_F(NVFuserTest, FusionMappingRelation_CUDA) {
 
   ComputeAtMap ca_map(fusion);
 
-  // FIXME: This is the concerning part that would motivate some
-  //  more formalization on concrete/permissive mapping:
-  //   exact mapping should ideally imply permissive mapping.
   auto tv4_inner_node = tv4->axis(0)->definition()->input(1)->as<IterDomain>();
   TORCH_CHECK(
       ca_map.areMapped(tv2->axis(0), tv4_inner_node, IdMappingMode::EXACT));
-  TORCH_CHECK(!ca_map.areMapped(
+  TORCH_CHECK(ca_map.areMapped(
       tv2->axis(0), tv4_inner_node, IdMappingMode::PERMISSIVE));
 
   auto options = at::TensorOptions().dtype(kFloat).device(at::kCUDA, 0);