RFR: 8160748: Inconsistent types for ideal_reg

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Apr 11 01:53:04 UTC 2017


On 4/10/17 6:00 PM, Kim Barrett wrote:
>> On Apr 10, 2017, at 3:43 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> Hi, Kim
>>
>> Please, also correct vector registers (need to fix *.ad files too):
>>
>>  // Vector ideal reg
>>  static const int vector_ideal_reg(int len);
>>  static const int vector_shift_count_ideal_reg(int len);
>
> Oops, I missed those.  Testing that change.  I’ll put out a new webrev when that’s done.
>
>> Can you do the same for OptoReg::reg2stack()? Or file separate RFE for it.
>
> I’m not sure what it is you are asking for here.

There are useless conversions there too. For example:

   static unsigned int reg2stack( OptoReg::Name r) {

       int stack_slot = reg2stack(n);

But it is a lot more changes since stack2reg(int idx) and others have singed argument. And I don't remember if negative 
values are used in such case. That is why I said may be to do it in separate RFE.

Vladimir

>
>> Thanks,
>> Vladimir
>>
>> On 4/7/17 12:21 PM, Igor Veresov wrote:
>>> Looks good to me.
>>>
>>> igor
>>>
>>>> On Apr 6, 2017, at 9:48 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>
>>>> Please review this change to Type's ideal_reg to make its return type
>>>> consistent with the closely related Node::ideal_reg().  Where Type
>>>> used to be an int, it is now a uint.  This eliminates the implicit
>>>> narrowing conversion in the initialization of _type_info that caused
>>>> build failure for C++11 (gcc with -std=gnu++11 or (not tested, but
>>>> presumed fixed) Visual Studio 2015 or later).
>>>>
>>>> Also fixed a number of places where the result of Node::ideal_reg()
>>>> was being treated as int rather than uint.
>>>>
>>>> And since I was in the neighborhood (changing the type of
>>>> Type::TypeInfo::ideal_reg), also fixed Type::_type_info[] to be const
>>>> as apparently intended but not successfully accomplished.  (The msg
>>>> member was writable, forcing allocation of the array to be in writable
>>>> memory, rather than read-only.)
>>>>
>>>> CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8160748
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~kbarrett/8160748/hotspot.00/
>>>>
>>>> Testing:
>>>> JPRT, rbt hs-tier2,hs-tier3,hs-tier4-comp,hs-tier5-comp
>
>


More information about the hotspot-compiler-dev mailing list