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

[David Chase]

My v9 manual might be a little dated, but according to it, annulling the delay slot instruction for an always-taken branch guarantees that the instruction following the branch will not be executed as a consequence of executing the branch (except for ba,a .+4).  There's no need to put a nop there.  This was certainly, absolutely true on V8 -- I did spend several years working on a code generator for that architecture, though it was 20 years ago.

David

On 2013-06-07, at 12:22 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> On 6/7/13 9:15 AM, David Chase wrote:
>> I think I'm confused.  If it's a ba,a (or the newer BPA,a,pt), there's no need for a NOP, since it is never executed.
>> We can save 4 whole bytes of code space/instruction cache.
> 
> ALL SPARC branch instructions, except new cbcond, HAVE delay slot instruction. Period! You only can control execution of delayed instruction with annulled bit.
> That is why on T4 cbcond was added. Traces showed that most instructions in delay slot are nops.
> 
> Vladimir
> 
>> 
>> David
>> 
>> On 2013-06-07, at 12:08 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> 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
>>>>>>>>> 
>>>>>>>>> 
>>>>>> 
>>>> 
>>