You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Cheng, BuQi (JIRA)" <ji...@apache.org> on 2008/10/11 20:51:44 UTC
[jira] Created: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
[HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
----------------------------------------------------------------------------------------------------------------
Key: HARMONY-5996
URL: https://issues.apache.org/jira/browse/HARMONY-5996
Project: Harmony
Issue Type: Bug
Environment: Windows
Reporter: Cheng, BuQi
Priority: Critical
In function code:
void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
....
Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
...
} else if (opcode == Op_AddScaledIndex &&
arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
assert(ldBaseInst == NULL);
ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
break;
}
}
...
}
The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
In server: scimark.sor.small.
After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
There may be two kind solutions:
1. In IR building, record the array access information.
2. Or more accurate symbolic is used to find the array base load instruction.
Thanks!
Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER]
Assumption in array base address load asscoiated symbolic analysis of dabce
caused bug
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638832#action_12638832 ]
Aleksey Shipilev commented on HARMONY-5996:
-------------------------------------------
Hi, BuQi!
1. Does this issue prevents scimark.lu.large to run? If yes, please state it in JIRA. If not, please down the priority to high.
2. Please also follow the general guideline for patch submission: do one solid patch for issue, relative to VM root, not some directory inside.
I hadn't looked into the patch yet.
Thanks,
Aleksey.
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug_cpp.patch, dabce_fillTemplate_bug_h.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Attachment: dabce_fillTemplate_bug_h.patch
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug_cpp.patch, dabce_fillTemplate_bug_h.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Attachment: dabce_fillTemplate_bug.cpp.patch
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug.cpp.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Attachment: (was: dabce_fillTemplate_bug_cpp.patch)
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Attachment: dabce_fillTemplate_bug.h.patch
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug.cpp.patch, dabce_fillTemplate_bug.h.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Attachment: dabce_fillTemplate_bug_cpp.patch
Patch which do more symoblic analysis for OP_LdArrayBaseAddr
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug_cpp.patch, dabce_fillTemplate_bug_h.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER]
Assumption in array base address load asscoiated symbolic analysis of dabce
caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638846#action_12638846 ]
Cheng, BuQi commented on HARMONY-5996:
--------------------------------------
scimark.sor.small failed because of another bug. I mistake it to be the bug caused by this issue. Sorry! This issue will only mkae scimark.lu.large failed to run.
Thanks!
Buqi
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug_cpp.patch, dabce_fillTemplate_bug_h.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Attachment: dabce_fillTemplate_bug.cpp.patch
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug.cpp.patch, dabce_fillTemplate_bug.h.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Attachment: (was: dabce_fillTemplate_bug_h.patch)
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Component/s: DRLVM
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER]
Assumption in array base address load asscoiated symbolic analysis of dabce
caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638844#action_12638844 ]
Cheng, BuQi commented on HARMONY-5996:
--------------------------------------
Hi Aleksey:
Yes, the issue prevents scimark.lu.large to run in server mode. So it's priority is high.
Thanks!
Buqi
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug_cpp.patch, dabce_fillTemplate_bug_h.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER] Assumption
in array base address load asscoiated symbolic analysis of dabce caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cheng, BuQi updated HARMONY-5996:
---------------------------------
Attachment: (was: dabce_fillTemplate_bug.cpp.patch)
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
> Attachments: dabce_fillTemplate_bug.h.patch
>
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5996) [HARMONY][JIT][OPTIMIZER]
Assumption in array base address load asscoiated symbolic analysis of dabce
caused bug
Posted by "Cheng, BuQi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638818#action_12638818 ]
Cheng, BuQi commented on HARMONY-5996:
--------------------------------------
Patch is added to solve the problem. More symbolic analysis is done for the LdArrayBaseAddr instruction finding.
sciamrk.lu.large passed regression, and DABCE for the target loop works.
> [HARMONY][JIT][OPTIMIZER] Assumption in array base address load asscoiated symbolic analysis of dabce caused bug
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5996
> URL: https://issues.apache.org/jira/browse/HARMONY-5996
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: Windows
> Reporter: Cheng, BuQi
> Priority: Critical
>
> In function code:
> void DynamicABCE::fillTemplate(ArrayAccessTemplate* arrayAccess, Inst* checkInst) {
> ....
> Node* node = checkInst->getNode()->getUnconditionalEdgeTarget();
> for (Inst* inst = (Inst*)node->getFirstInst(); inst != NULL; inst = inst->getNextInst()) {
> ...
> } else if (opcode == Op_AddScaledIndex &&
> arrayAccess->index == inst->getSrc(1) && arrayAccess->array == NULL) {
> assert(ldBaseInst == NULL);
> ldBaseInst = inst->getSrc(0)->asSsaOpnd()->getInst();
> assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);
> arrayAccess->array = ldBaseInst->getSrc(0)->asSsaOpnd();
> break;
> }
> }
> ...
> }
> The code "assert(ldBaseInst->getOpcode() == Op_LdArrayBaseAddr);" assumes that after bound checking, the direct target block will access array immediately, and the array access instruction in it will use "Op_LdArrayBaseAddr" instruction to access the array base. However, this kind assumption is very tender.
> In server: scimark.sor.small.
> After loop peeling, phi instruction is generated for LDBASE instruction, this time LDVAR instruction will be used to get the variable from Phi. The assertion will fail and bug will happen.
> There may be two kind solutions:
> 1. In IR building, record the array access information.
> 2. Or more accurate symbolic is used to find the array base load instruction.
> Thanks!
> Buqi
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.