[code-reflection] RFR: Support storing the code that builds the code model [v18]

[Maurizio Cimadamore]

On Thu, 13 Mar 2025 15:01:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
>> 
>>  - Merge branch 'code-reflection' into code-model-storage-option
>>  - Load OpFactory and TypeElementFactory before invocation of opMethod only if the opMethod has there params.
>>  - Fix the remaining compiler tests failures
>>  - Fix some of the test failures (3 remains)
>>  - Fix the remaining test failures of SwitchExpressionTest2
>>  - Fix almost all test failures of SwitchExpressionTest2 (one remaining)
>>  - Pass arrayType instead of eleType in OpBuilder.buildArray
>>  - Ensure that block params are inserted in the correct order
>>  - Add missing imports
>>  - Merge branch 'code-reflection' into code-model-storage-option
>>  - ... and 10 more: https://git.openjdk.org/babylon/compare/07cefe5c...966005ce
>
> 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)

-------------

PR Review Comment: https://git.openjdk.org/babylon/pull/305#discussion_r1993755791