RFR(S): 8035283 Second phase of branch shortening doesn't account for loop alignment

[Igor Veresov]

Rickard,

That’d be a pretty fine-grain factoring (and will have 2-4 arguments) compared to everything else in the module. I agree that, perhaps, functions in output.cpp are a tad too big and could be factored, but I’d like this fix to be minimal because I’ll need to backport it pretty much everywhere. So, I’d rather leave it as is.

Thanks!
igor

On Feb 19, 2014, at 10:21 PM, Rickard Bäckman <rickard.backman at oracle.com> wrote:

> Igor,
> 
> might just be me but could you extract that logic into its own method?
> 
> Thanks
> /R
> 
> On 02/19, Igor Veresov wrote:
>> Branch shortening should take care of the case when a there is an “avoid-back-to-back” instruction in the loop header preceded by the block with another “avoid-back-to-back” instruction with the loop padding. The machinery did not account for the fact the padding can be completely eliminated during the emission.
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8035283/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8035283
>> 
>> Testing: the affected application, CTW, jtreg (on SPARC-T4 with loop alignment 4 and 16), jprt
>> 
>> Thanks!
>> igor