AARCH64: 8139041: Redundant DMB instructions (CORRECTED )
Vladimir Kozlov
vladimir.kozlov at oracle.com
Sat Oct 10 01:00:17 UTC 2015
On 10/10/15 2:47 AM, Christian Thalinger wrote:
>
>> On Oct 9, 2015, at 5:37 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> Hi,
>>
>> On 10/09/2015 03:59 PM, Roland Westrelin wrote:
>>
>>>> There is a much simpler way: remove adjacent barriers in
>>>> MacroAssembler. Thanks to the way that the AArch64 ISA is designed,
>>>> barriers can be merged simply by ORing them together. Of course, this
>>>> technique works for C1 and C2, and it adds essentially nothing to the
>>>> compilation time.
>>>>
>>>> http://cr.openjdk.java.net/~aph/8139041/
>>>>
>>>> One thing which may be controversial is that I've added a field to
>>>> CodeBuffer to keep track of barriers and labels. I had to do this
>>>> because when we're compiling there is (AFAICS) essentially nowhere
>>>> else to keep the state.
>
> I don’t think it matters to have an additional field in CodeBuffer. It’s a temporary data structure and we use much more memory for graphs.
>
> I would even go that far and questioning putting it under #ifdef AARCH64.
+1 that.
Vladimir
>
>>>
>>> Isn’t your new field a bit like:
>>>
>>> address insts_mark() const { return _insts.mark(); }
>>> void set_insts_mark() { _insts.set_mark(); }
>>> void clear_insts_mark() { _insts.clear_mark(); }
>>>
>>> which is used in very few locations AFAIK. Do you think you could reuse that one?
>>
>> Yes, that's what it's based on. I guess that is possible in theory,
>> but AbstractAssembler::InstructionMark() looks like this:
>>
>> InstructionMark(AbstractAssembler* assm) : _assm(assm) {
>> assert(assm->inst_mark() == NULL, "overlapping instructions");
>> _assm->set_inst_mark();
>> }
>>
>> so any instruction which leaves the mark set will trigger an assertion
>> failure the next time InstructionMark is used. I suppose that in
>> extremis I could make every instruction which is not a memory barrier
>> clear the mark, but ewww. :(
>>
>> I suppose I could define an AArch64-specific version of
>> InstructionMark which does not have this assert, but I'm not sure I
>> like that either.
>>
>> [An aside: we use InstructionMark unnecessarily in AArch64, and it's
>> on my list of things to remove, but that's for another day.]
>>
>> Thanks for looking at this,
>>
>> Andrew.
>
More information about the hotspot-compiler-dev
mailing list