Handle jitNewValue in code generators #8520
Conversation
|
implementation seems reasonable - could we create a capability query (maybe on object model?) to store whether value types are supported and use the macro to determine the result to be returned. Ideally, the function should be inlined by the compiler so the dead code is removed. |
Leonardo2718
force-pushed
the
jitnewvalue
branch
from
9e1318d
to
ec63d09
Compare
|
@andrewcraik As suggested, I've added a query to the object model in |
Leonardo2718
force-pushed
the
jitnewvalue
branch
2 times, most recently
from
30d16a6
to
ecf8e52
Compare
|
@gita-omr and @fjeremic could you review the codegen part of the change - this is some helpers needed for value types - performance is not critical at this point, we need functionality so we are just always going to call the helper. Improvements to follow later once we have the JIT functional using only helper calls. Would be ideal to get this merged in the next day or so if possible. |
|
Jenkins test sanity all jdk8 |
|
Would it be possible to add a link to the main issue that contains the whole value type design? |
|
@gita-omr that overarching issue has not been populated - I'll let @tajila add a link once he has something setup. @Leonardo2718 build failures on ppc - please investigate. |
Leonardo2718
force-pushed
the
jitnewvalue
branch
from
ecf8e52
to
ec8fd52
Compare
|
@andrewcraik Power build failures should be fixed now. |
|
Jenkins test sanity all jdk11 |
|
Other than the use of auto in place of TR::Compilation this looks good. |
This new query allows checking for value types support with a function call instead of an #ifdef. Although it is currently a compile type option, value types support will eventually be decided at runtime, so using a function call now is preferable to using an #ifdef everywhere. Signed-off-by: Leonardo Banderali <leonardo2718@protonmail.com>
Leonardo2718
force-pushed
the
jitnewvalue
branch
from
ec8fd52
to
c78cc88
Compare
Because `newvalue` support is not implemented in the code generators, the opcode is lowered to `new`. When lowering happens, the symbol on the `new` is set to be the same as the one for `newvalue`, namely jitNewValue. As a result, `new` evaluators must check the node's symbol to determine if the allocation is for a value type. To avoid having to implement full support for inline value type allocations, for now, we unconditionally call the JIT helper. While not ideal for performance, it is a necessary step in incrementally implementing value types. Note that the AARCH64 code generator already calls whatever helper is set on the `new` node unconditionally, so no special handling for jitNewValue is required. Signed-off-by: Leonardo Banderali <leonardo2718@protonmail.com>
Some file in the POWER and ARM code generators are guarded with TR_TARGET_ARM and TR_TARGET_POWER, respectively. These are unnecessary because those files are only ever built on their respective platform. Signed-off-by: Leonardo Banderali <leonardo2718@protonmail.com>
Leonardo2718
force-pushed
the
jitnewvalue
branch
from
c78cc88
to
ad62d30
Compare
|
Jenkins test sanity all jdk11 |
|
Jenkins test xlinux jdk11 |
|
xlinux failure is infra - everything else is good so I will merge this. |
Because
newvaluesupport is not implemented in the code generators, the opcode is lowered tonew. When lowering happens, the symbol on thenewis set to be the same as the one fornewvalue, namely jitNewValue.As a result,
newevaluators must check the node's symbol to determine if the allocation is for a value type.To avoid having to implement full support for inline value type allocations, for now, we unconditionally call the JIT helper. While not ideal for performance, it is a necessary step in incrementally implementing value types.
Note that the AARCH64 code generator already calls whatever helper is set on the
newnode unconditionally, so no special handling for jitNewValue is required.