RFR(S): 8172145: C2: anti dependence missed because store hidden by membar
Vladimir Kozlov
vladimir.kozlov at oracle.com
Mon Jan 2 20:47:59 UTC 2017
I think the problem is this:
"The membar's adr_type is NULL so can_alias returns false and reordering is not prevented."
It should not be NULL. Type should be TypePtr::BOTTOM or specific memory related type.
Loads should not be moved below membar if membar is wide (TypePtr::BOTTOM, affect all memory).
It would be interesting to see these nodes in Ideal graph. What memory connections there?
if (support_IRIW_for_not_multiple_copy_atomic_cpu && field->is_volatile()) {
insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier
Node* GraphKit::insert_mem_bar(int opcode, Node* precedent) {
MemBarNode* mb = MemBarNode::make(C, opcode, Compile::AliasIdxBot, precedent);
and
_alias_types[AliasIdxBot]->Init(AliasIdxBot, TypePtr::BOTTOM);
So I don't get why you have "adr_type is NULL"
Thanks,
Vladimir
On 12/30/16 7:34 AM, Andrew Haley wrote:
> Hi,
>
> On 30/12/16 13:29, Doerr, Martin wrote:
>>
>> we found a C2 Compiler bug which leads to incorrect reordering of
>> memory accesses on PPC64 due to missing anti-dependency. Details are
>> described here: https://bugs.openjdk.java.net/browse/JDK-8172145
>
> Another missing anti-dependency!
>
>> The issue can be fixed by this webrev:
>> http://cr.openjdk.java.net/~mdoerr/8172145_C2_antidep/webrev.00/
>
> Wouldn't it make more sense to calculate is_Mach_MemBarVolatile lazily?
>
> Andrew.
>
More information about the hotspot-compiler-dev
mailing list