Add test to check against sharpening optimization
After b/214850438 we took a second look at the sharpening optimization.
While it seems doable, it is not straightforward. We are adding a
comment and a test to make sure we are not mistakenly enabling it.
Test: art/test/testrunner/testrunner.py --host --64 --optimizing -b
Bug: 214850438
Bug: 154012332
Change-Id: Ic619934cdd4cd322a31afce60b9becbfa4338e81
diff --git a/compiler/optimizing/sharpening.cc b/compiler/optimizing/sharpening.cc
index 1fd76f7..8794d5a 100644
--- a/compiler/optimizing/sharpening.cc
+++ b/compiler/optimizing/sharpening.cc
@@ -283,6 +283,12 @@
// We actually cannot reference this class, we're forced to bail.
// We cannot reference this class with Bss, as the entrypoint will lookup the class
// in the caller's dex file, but that dex file does not reference the class.
+ // TODO(solanes): We could theoretically enable this optimization for kBssEntry* but this
+ // requires some changes to the entrypoints, particularly artResolveTypeFromCode and
+ // artResolveTypeAndVerifyAccessFromCode. Currently, they assume that the `load_class`'s
+ // Dexfile and the `dex_compilation_unit` DexFile is the same and will try to use the type
+ // index in the incorrect DexFile by using the `caller`'s DexFile. A possibility is to add
+ // another parameter to it pointing to the correct DexFile to use.
return HLoadClass::LoadKind::kInvalid;
}
}