AARCH64: 8139041: Redundant DMB instructions (CORRECTED )
Andrew Haley
aph at redhat.com
Fri Oct 9 15:37:22 UTC 2015
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.
>
> 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