[code-reflection] RFR: Support storing the code that builds the code model [v18]
Maurizio Cimadamore
mcimadamore at openjdk.org
Wed Mar 26 09:53:31 UTC 2025
On Thu, 13 Mar 2025 15:10:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeModelToAST.java line 117:
>>
>>> 115: var restype = typeElementToType(invokeOp.resultType());
>>> 116: var type = new Type.MethodType(paramTypes, restype, List.nil(), syms.methodClass);
>>> 117: var methodSym = new Symbol.MethodSymbol(flags, name, type,
>>
>> Same as for field access (see below) -- we should not create a new method symbol from scratch but "resolve" a method in a given class symbol (using `Resolve::findInternalMethod`)
>
> I suggest to add two helper methods -- one takes a FieldDescriptor and returns a VarSymbol (using `Resolve::findFieldInternal` -- the other takes a MethodDescriptor and returns a MethodSymbol (using `Resolve::findMethodIntenal`. Then you rewrite the code here (and in field access) to use these methods.
This is related to the one above for var symbol -- creating method/var symbols directly in the backend is not the way to do things -- we should lean on `Resolve` instead. It would be nice to fix these -- but we can also take another pass at it later if required.
>> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeModelToAST.java line 239:
>>
>>> 237: }
>>> 238:
>>> 239: public static CoreOp.FuncOp addVarsWhenNecessary(CoreOp.FuncOp funcOp) {
>>
>> Maybe I'm missing something obvious. But if you have something like:
>>
>> func @"f" ()java.util.Map -> {
>> %0 : java.util.Map<java.lang.Integer, java.lang.Integer> = new @"func<java.util.HashMap>";
>> %1 : int = constant @"1";
>> %2 : int = constant @"2";
>> %3 : java.lang.Object = invoke %0 %1 %2 @"java.util.Map::put(java.lang.Object, java.lang.Object)java.lang.Object";
>> return %0;
>> }
>>
>>
>> Can't we translate as:
>>
>>
>> Map $0 = new HashMap();
>> int $1 = 1;
>> int $2 = 3;
>> Object $3 = $0.put($1, $2);
>> return $0;
>>
>>
>> Note how this translation is very 1-1 and direct, and doesn't require any adaptation step in the model. We just emit a new local variable for each op we see in the body -- and then refer to operands via their corresponding (locally declared) variable.
>
> (of course we'd only do the above translation for ops that have a non-void result type)
We can follow up on this improved translation at a later point.
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/305#discussion_r2013758784
PR Review Comment: https://git.openjdk.org/babylon/pull/305#discussion_r2013751016
More information about the babylon-dev
mailing list