8230015: [instruction selector] generic vector operands support.
Leslie Zhai
zhaixiang at loongson.cn
Thu Apr 15 03:57:05 UTC 2021
Hi Vladimir,
Thanks for your kind response!
在 2021年04月15日 01:11, Vladimir Ivanov 写道:
> Hi Leslie,
>
> I'm not sure what you are trying to achieve with the port.
SPECjvm2008 some benchmarks performed better after ported Vector API for
YOURARCH, but libjvm.so became fatter. So I tried to port Generic
Vector Operands for losing weight.
>
>
> Currently, there are 3 platform-specific methods which
> Matcher::do_postselect_cleanup() relies on:
>
> Matcher::pd_specialize_generic_vector_operand()
> Matcher::is_generic_reg2reg_move()
> Matcher::is_generic_vector()
There is no `vec` move to `legVec` or `legVec` to `vec`:
diff --git a/src/hotspot/cpu/yourarch/yourarch_64.ad
b/src/hotspot/cpu/yourarch/yourarch_64.ad
index f3cdc560372..a2beb6bc776 100644
--- a/src/hotspot/cpu/yourarch/yourarch_64.ad
+++ b/src/hotspot/cpu/yourarch/yourarch_64.ad
@@ -1104,22 +1104,32 @@ const bool Matcher::require_postalloc_expand =
false;
// the cpu only look at the lower 5/6 bits anyway?
const bool Matcher::need_masked_shift_count = false;
-// No support for generic vector operands.
-const bool Matcher::supports_generic_vector_operands = false;
+const bool Matcher::supports_generic_vector_operands = true;
MachOper* Matcher::pd_specialize_generic_vector_operand(MachOper*
generic_opnd, uint ideal_reg, bool is_temp) {
- ShouldNotReachHere(); // generic vector operands not supported
+ assert(Matcher::is_generic_vector(generic_opnd), "not generic");
+ switch (ideal_reg) {
+ case Op_VecS: return new vecSOper();
+ case Op_VecD: return new vecDOper();
+ case Op_VecX: return new vecXOper();
+ case Op_VecY: return new vecYOper();
+ }
+ ShouldNotReachHere();
return NULL;
}
+// No vec move to legVec or legVec to vec
bool Matcher::is_generic_reg2reg_move(MachNode* m) {
- ShouldNotReachHere(); // generic vector operands not supported
return false;
}
bool Matcher::is_generic_vector(MachOper* opnd) {
- ShouldNotReachHere(); // generic vector operands not supported
- return false;
+ switch (opnd->opcode()) {
+ case VEC:
+ return true;
+ default:
+ return false;
+ }
}
bool Matcher::supports_vector_variable_shifts(void) {
@@ -2745,6 +2755,19 @@ ins_attrib ins_alignment(4); // Required
alignment attribute (must be a power
// Vectors
+// Dummy generic vector class. Should be used for all vector operands.
+// Replaced with vec[SDXY] during post-selection pass.
+operand vec() %{
+ constraint(ALLOC_IN_RC(dynamic));
+ match(VecX);
+ match(VecY);
+ match(VecS);
+ match(VecD);
+
+ format %{ %}
+ interface(REG_INTER);
+%}
+
operand vecS() %{
constraint(ALLOC_IN_RC(vectors_reg));
match(VecS);
Then merged loadV4/8/16/32 into loadV and storeV4/8/16/32 to storeV with
the helper functions `vector_length_in_bytes` for LoadVector and
StoreVector at first.
>
>
> It should be enough to provide implementations for those methods on
> YOURARCH to make Matcher::do_postselect_cleanup() working.
It is my fault: other VectorNodes, for example, `MulVD` and `ReplicateD`
also need to change `vecX/Y` to `vec` in the very beginning, not only
just LoadVector/StoreVector. Sorry that I am too hurry to see the
optimization effect.
>
>
> Can you elaborate on what exactly you are trying to accomplish?
Better SPECjvm2008 benchmark performance and meanwhile libjvm.so keep
slim :)
Thanks,
Leslie Zhai
>
>
> Best regards,
> Vladimir Ivanov
>
> On 14.04.2021 08:09, Leslie Zhai wrote:
>> Hi Jatin,
>>
>> Thanks for your great work!
>>
>> libjvm.so reduced +1MB will help SPECjvm2008 some benchmark +44%
>> speed up.
>>
>> Then I tried to port 8234391: C2: Generic vector operands for
>> `YOURARCH` about LoadVector and StoreVector at first.
>>
>> Only `Matcher::regmask_for_ideal_register` was able to call
>> `Matcher::is_generic_vector`, but compared with X86,
>> `Matcher::do_postselect_cleanup` was also able to call
>> `Matcher::is_generic_vector` too.
>>
>> I debug the `Matcher::do_postselect_cleanup`:
>>
>> diff --git a/src/hotspot/share/opto/matcher.cpp
>> b/src/hotspot/share/opto/matcher.cpp
>> index 0846cad3c3f..8fd644d2d93 100644
>> --- a/src/hotspot/share/opto/matcher.cpp
>> +++ b/src/hotspot/share/opto/matcher.cpp
>> @@ -309,6 +309,9 @@ void Matcher::match( ) {
>> C->record_method_not_compilable("must be able to represent all
>> call arguments in reg mask");
>> }
>>
>> +#ifdef YOURARCH64
>> + do_postselect_cleanup();
>> +#endif
>> if (C->failing()) return; // bailed out on incoming arg failure
>>
>> // ---------------
>> @@ -2630,8 +2633,10 @@ void
>> Matcher::specialize_generic_vector_operands() {
>> int opnd_idx = m->operand_index(1);
>> Node* def = m->in(opnd_idx);
>> m->subsume_by(def, C);
>> +#if !defined(YOURARCH64)
>> } else if (m->is_MachTemp()) {
>> // process MachTemp nodes at use site (see
>> Matcher::specialize_vector_operand)
>> +#endif
>> } else {
>> specialize_mach_node(m);
>> }
>>
>> But `Matcher::do_postselect_cleanup` was still not able to be called.
>>
>>> Current patch enables this support only for x86 target, to get a
>> feedback from community.
>>
>> Then how to port Generic vector operands for other targets?
>>
>> Thanks,
>>
>> Leslie Zhai
>>
>>
>> 在 2019年08月22日 14:49, Bhateja, Jatin 写道:
>>> Hi All,
>>>
>>> Please find below a patch for generic vector operands[1] support
>>> during instruction selection.
>>>
>>> Motivation behind the patch is to reduce the number of vector
>>> selection patterns whose operands meagerly differ in vector lengths.
>>> This will not only result in lesser code being generated by ADLC
>>> which effectively translates to size reduction in libjvm.so but also
>>> help in better maintenance of AD files.
>>>
>>> Using generic operands we were able to collapse multiple vector
>>> patterns over mainline
>>> Initial number of vector instruction patterns
>>> (vec[XYZSD] + legVec[ZXYSD] : 510
>>> Reduced vector instruction patterns (vecG +
>>> legVecG) : 222
>>>
>>> With this we could see around 1MB size reduction in libjvm.so.
>>>
>>> In order to have minimal impact over downstream compiler passes, a
>>> post-selection pass has been introduced (currently enabled only for
>>> X86 target)
>>> which replaces these generic operands with their corresponding
>>> concreter vector length variants.
>>>
>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8230015
>>> Patch :
>>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/
>>>
>>> Kindly review and share your feedback.
>>>
>>> Best Regards,
>>> Jatin Bhateja
>>>
>>> [1]
>>> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf
>>>
>>>
>>
More information about the hotspot-compiler-dev
mailing list