RFR(S): 8179618: Fixes for range of OptoLoopAlignment and Inlining flags

[Lindenmaier, Goetz]

Hi Thomas, 

thanks for looking at my change.
New webrev:
http://cr.openjdk.java.net/~goetz/wr17/8179618-FlagRanges/webrev.02/

> c2_globals.hpp:
> -          range(0, max_intx)                                                \
> +          range(0, ((intx)MIN2((int64_t)max_intx,(int64_t)(+1.0e10))))      \
> 32bit: I would have expected a build warning for the cast. Is it okay that we can never reach the max value on 32bit?

I double checked that there is no warning in our night builds and on linuxintel.

> commandLineFlagConstraintsCompiler.cpp:
>      CommandLineError::print(verbose,
>                              "OptoLoopAlignment (" INTX_FORMAT ") must be "
>                              "multiple of NOP size\n");
> There is an error here, the print parameter is missing. Would have expected the compiler to complain, actually - at least the gcc. Again, curious.

Thanks, good catch! The error was there before, but fixed anyways. I also 
added the NOP size.

Best regards,
  Goetz.



Kind Regards, Thomas

On Thu, May 4, 2017 at 12:57 PM, Lindenmaier, Goetz <mailto:goetz.lindenmaier at sap.com> wrote:
Hi,
 
This change fixes range handling of a few flags of C2.
This should go to jdk10, and later be downported to some
update of jdk9.
 
Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8179618-FlagRanges/webrev.01/
 
Class WarmCallInfo limits its values to 1.0e10, but the flags used
to set it's fields (HotCallCountThreshold etc.) are limited by max_intx.
Using values over 1.0e10 causes assertions in the debug build.
 
OptoLoopAlignment must be a multiple of nop size, else it's not
possible to generate the instructions that go into the pad.
On x86 NOP size is 1, so it's no problem.
For SPARC, OptoLoopAlignmentConstraintFunc implements a special 
case for bigger NOPs. This is also needed for s390 and ppc.
I just removed the #define, as the code works also on platforms
where NOPsize == 1. Actually, it should be optimized by the C 
compiler in these cases.
 
Best regards,
  Goetz.