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

Morris Meyer morris.meyer at oracle.com
Fri Jun 7 06:24:01 PDT 2013


I substituted instructions from the non-cbcond path of ba_short():

// Unconditional short branch
void MacroAssembler::ba_short(Label& L) {
   if (use_cbcond(L)) {
     Assembler::cbcond(equal, icc, G0, G0, L);
     return;
   }
   br(always, false, pt, L);
   delayed()->nop();
}

Should w file a follow-on issue to address ba_short)() and 
eden_allocate() in MacroAssembler - or should we change both and re-run 
the JPRT job?

         --mm


On 6/7/13 7: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
>>>>
>>>>



More information about the hotspot-compiler-dev mailing list