RFR(XS): 8015437: SPARC cbcond offset value out of range

[Vladimir Kozlov]

On 6/7/13 8:56 AM, David Chase wrote:
> Wouldn't we want to call it ba_without_delay or something like that?

It could be misleading since it could be interpreted as without delay 
slot. Our case is nop in delay slot which we should not execute.
We can use neutral name ba_long() as opposite to ba_short().

Vladimir

>
> David
>
> On 2013-06-07, at 11:47 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> David is right.
>>
>> We have a lot of places in sparc code where we are sloppy with annulled bit for direct branch and nop() in delay slot. I count about 10 cases which br() instruction and 15 with ba() which is not really bad.
>>
>> We need separate macroassembler instruction for such case.
>> ba_with_nop()?
>>
>> Good starter task :)
>>
>> Thanks,
>> Vladimir
>>
>> On 6/7/13 4:59 AM, David Chase wrote:
>>> Huh.  ba,a (annulled branch -- if I recall, the sense of the annulled bit is reversed for ba) ought to get the job done without the delay-slot nop.
>>>
>>> David
>>>
>>> On 2013-06-07, at 6:54 AM, Morris Meyer <morris.meyer at oracle.com> wrote:
>>>
>>>> I needed to have the delayed()->nop() in there as ba() crashed for me.
>>>>
>>>>
>>>>       --mm
>>>>
>>>>
>>>> On Jun 7, 2013, at 12:35 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>
>>>>> Morris,
>>>>>
>>>>> Why you used br(always, false, pt, slow_case) instead of ba(slow_case)?
>>>>>
>>>>> Which is the same but simpler and it was specially added to avoid messing with parameters of br() instruction.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 6/6/13 9:22 PM, Morris Meyer wrote:
>>>>>> Folks,
>>>>>>
>>>>>> Could I get a review for this issue?  The problem exists that we
>>>>>> optimistically assign forward branch labels and re-patch later. When we
>>>>>> emit a cbcond instruction - we check if the Label out of bounds.  If it
>>>>>> is already bound the check is fine - if not bound a zero offset is
>>>>>> emitted and the label is patched later
>>>>>>
>>>>>> With Vladimir Kozlov's urgings I put about 4,000 lines of changes to add
>>>>>> __FILE__ and __LINE__ parameters to every assembler.bind() call and
>>>>>> checked the return of every patched branch to find out the line and
>>>>>> location of the offending bind.  The bind distance from
>>>>>> NewInstanceStub::emit_code() in c1_CodeStubs_sparc.cpp was to far from
>>>>>> __ allocate_object macro assembler call in LIRGenerator::new_instance
>>>>>> which uses the short branch in MacroAssembler::eden_allocate()
>>>>>>
>>>>>> This change has been through JPRT.
>>>>>>
>>>>>>         --morris
>>>>>>
>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8015437.01
>>>>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-8015437
>>>>>>
>>>>>>
>>>
>