RFR(M): 8167184: [s390] Extend relocations for pc-relative instructions.

[Vladimir Kozlov]

Good.

Thanks,
Vladimir

On 10/10/16 2:36 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
> I added S390_ONLY macros around the field declaration and the two
> methods so that set_ctable_begin should be inlined as empty method
> and optimized away on non-s390 platforms.
> http://cr.openjdk.java.net/~goetz/wr16/8167184-s390_relocations/webrev.02/
>
> Best regards,
>   Goetz.
>
>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Donnerstag, 6. Oktober 2016 18:34
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-compiler-
>> dev at openjdk.java.net
>> Subject: Re: RFR(M): 8167184: [s390] Extend relocations for pc-relative
>> instructions.
>>
>> On 10/6/16 8:48 AM, Lindenmaier, Goetz wrote:
>>> Hi Vladimir,
>>>
>>> your're right, adding a field to CodeBlob will blow up nmethods on all
>>> platforms, so I agree having an #ifdef makes sense.
>>> But for the relocation, it's just an extra class, should not
>>> matter too much, but it's much clearer than adding #ifdefs I think.
>>
>> Okay, I am fine with new relocation class since it is not used on other
>> platforms.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> I edited the bug to mention 'constant section".
>>>
>>> Best regards,
>>>   Goetz.
>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Mittwoch, 5. Oktober 2016 20:27
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-
>> compiler-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR(M): 8167184: [s390] Extend relocations for pc-relative
>>>> instructions.
>>>>
>>>> When you say "constant pool" do you mean "conatant section" in code
>>>> buffer? Or CP in class data? I assume first. It is confusing.
>>>>
>>>> Can you implement this as S390 code (#ifdef)? I am not comfortable that
>>>> code is executed on other platforms too (ctable setting).
>>>>
>>>> Can you add _offset under #ifdef to runtime_call_Relocation instead? I
>>>> see that s390 code use it this way:
>>>>
>>>> +    if (type() == relocInfo::runtime_call_type) {
>>>> +      toc_offset = ((runtime_call_Relocation
>>>> *)this)->get_constant_pool_offset();
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 10/5/16 8:16 AM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> This extension to relocations is needed for the s390 port.
>>>>>
>>>>> Please review:
>>>>>
>>>>> http://cr.openjdk.java.net/~goetz/wr16/8167184-
>>>> s390_relocations/webrev.01/
>>>>>
>>>>>
>>>>> This change implements two extensions to relocation to support
>>>>> pc-relative instructions.
>>>>>
>>>>> On s390, there are call instructions that branch to an address relative
>>>>> to the current pc. If the offset encodable in the instruction does not
>>>>> suffice,  our port uses a pc-relative load to load the target address
>>>>> from the constant pool into a register that is then used as branch
>>>>> target. Relocations must support switching between these two
>>>>> implementations. For this we need a relocation that stores the offset of
>>>>> the address in the constant pool, as this value can not be read from the
>>>>> instruction.
>>>>>
>>>>> Further the pc-relative instructions encode the offset from the
>>>>> instruction to the constant. If the constant pool is resized, or the
>>>>> instruction is moved (as during shorten branches), this offset must be
>>>>> adapted. To compute the new offset, the change in offset must be
>> known.
>>>>> To compute this we store the position of the constant pool in the
>>>> CodeBlob.
>>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>>   Goetz.
>>>>>