code hoisting and optimization

Haluk Dogan hlk.dogan at gmail.com
Sun Sep 24 19:56:50 UTC 2017


Hi Josef,

Thank you for your answer, it helped me to make a progress. The reason for
why I am playing with optimization methods is that I was wondering if
compiler finds the best optimization plan when compiling the method.

To test, I defined a very simple code hoisting example as in the following,
and I called it CompilerTuned in my testing:

public static int[] codeHoisting(int x, int y, int n) {
    int[] result = new int[n];

    for (int i = 0; i < n; i++) {
        result[i] = x + y;
    }

    return result;
}

Then I measure the target bytecode size, since this example is very simple
to test runtime performance.

In the following, I described the terms I used for testing:

- Unoptimized: OptimisticOptimizations.NONE
- Optimized: OptimisticOptimizations.ALL
- Only High: Only kept the methods in HighPhase
- Only Mid: Only kept the methods in MidPhase
- Only Low: Only kept the methods in LowPhase
- High & Mid: Only kept the methods in High and Mid Phases
- High & Low: Only kept the methods in High and Low Phases
- Mid & Low: Only kept the methods in Mid and Low Phases

I also defined another method called codeHoistingOptimized as in the
following, and I called it ManuallyTuned in my testing:

public static int[] codeHoistingOptimized(int x, int y, int n) {
    int[] result = new int[n];
    int sum = x + y;

    for (int i = 0; i < n; i++) {
        result[i] = sum;
    }

    return result;
}

Moreover, I tried to find optimization plans to reduce the target bytecode
size via Monte-Carlo Search, and the best numbers are 325 for
CompilerTuned, and 305 for Manually Tuned after half million iteration.
Albeit, I could find different plans for these numbers.

Do you folks think that the idea for searching optimization plans make
sense?

Also, GuardLoweringPhase, LoweringPhase, and FrameStateAssignmentPhase in
MidPhase, LoweringPhase, AddressLoweringPhase, and SchedulePhase in
LowPhase are mandatory. I got exceptions when I took them out.

These are the numbers I got for different plans both for CompilerTuned and
ManuallyTuned:

+----------------+-------------+--------------------------+
|                |     Plan    | Target Code Size (bytes) |
+----------------+-------------+--------------------------+
| Compiler Tuned | Unoptimized |            385           |
+----------------+-------------+--------------------------+
|                |  Optimized  |            379           |
+----------------+-------------+--------------------------+
|                |  Only High  |            407           |
+----------------+-------------+--------------------------+
|                |   Only Mid  |            331           |
+----------------+-------------+--------------------------+
|                |   Only Low  |            325           |
+----------------+-------------+--------------------------+
|                | High & Mid  |            385           |
+----------------+-------------+--------------------------+
|                | High & Low  |            379           |
+----------------+-------------+--------------------------+
|                | Mid & Low   |            331           |
+----------------+-------------+--------------------------+
| Manually Tuned | Unoptimized |            377           |
+----------------+-------------+--------------------------+
|                |  Optimized  |            371           |
+----------------+-------------+--------------------------+
|                |  Only High  |            407           |
+----------------+-------------+--------------------------+
|                |   Only Mid  |            311           |
+----------------+-------------+--------------------------+
|                |   Only Low  |            305           |
+----------------+-------------+--------------------------+
|                | High & Mid  |            377           |
+----------------+-------------+--------------------------+
|                | High & Low  |            371           |
+----------------+-------------+--------------------------+
|                | Mid & Low   |            311           |
+----------------+-------------+--------------------------+

Thank you.

Best,
Haluk

On Tue, Sep 12, 2017 at 2:56 AM, Josef Eisl <josef.eisl at jku.at> wrote:

> Hello Haluk!
>
> (I move the discussion to the list since it seems related to your
> previous post.)
>
> On 11/09/17 17:27, Haluk Dogan wrote:
> > Dear Josef,
> >
> > I'm playing with Graal compiler. I've some applications in my mind, and
> > hopefully I can proceed with Graal for these applications.
> >
> > I'm particular interested in applying specific code optimizations. I
> > have this dummy code to play with:
> >
> > https://gist.github.com/anonymous/e546ee6db622976f109f71b70ade856b
> >
> > I defined a code hoisting example to see the optimization effect. In
> > fact, target code size is different for with and without optimizations.
> >
> > My question is, how can I apply a specific optimization technique in
> > Graal? I don't know much about GCC but I think in GCC we can apply
> > particular optimization technique with -f parameter.
> >
> > http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Optimize-Options.html
>
> First off a little bit of background, just in case your are not yet
> familiar with the terms used in the project. In Graal optimizations are
> organized as `Phases` and phases are organized in `PhaseSuites`. There
> are 3 suites: `HighTier`, `MidTier`, and `LowTier`. Those capture
> roughly the state transformation of the Graph, i.e., from a high level
> (Java'ish) point of view to a low level one (closer to the machine
> level). Then there are also `CompilerConfigurations` which select the
> set of suites used for a compilation.
>
> Now to your question: the programmatic way of changing the behavior is
> to modify the `PhaseSuites`, e.g. with PhaseSuite#appendPhase.
>
> Many phases can also be switched on and off via command line options,
> however there is no "default" switch for that. Have a look at the
> `HighTier`, `MidTier`, `LowTier` classes to get to know the option
> names. For example the HighTier makes use of the `FullUnroll` option
> which means you can turn of the `LoopFullUnrollPhase` with the
> `-Dgraal.FullUnroll=false` command line flag.
>
> I hope that gives you a few pointers. Feel free to ask if there are
> further questions.
>
> Josef
>
> >
> > Thanks.
> >
> > Best,
> > Haluk
> >
> > --
>
> On 07/09/17 03:48, Haluk Dogan wrote:
> > Hello,
> >
> > I'm trying to see the optimization steps by using Graal. I defined a
> > codeHoisting method in my Example class as in the following:
> >
> > public class Example {
> >
> >     public int[] codeHoisting(int x, int y, int n) {
> >         int[] result = new int[n];
> >         for (int i = 0; i < n; i++) {
> >             result[i] = x + y;
> >         }
> >         return result;
> >     }
> >
> > }
> >
> > Then, I used *compileAndInstallMethod* as shown in the Tutorial slides to
> > get the compiled code of given method. However, the resulting byte array
> is
> > different no matter we apply ALL or NONE optimizations.
> >
> > I would expect the same byte array after we apply
> > OptimisticOptimizations.ALL.
> >
> > Why the resulting byte arrays are different? Also, how can I print the
> > bytecode?
> >
> > I put the gist of the code in the following link:
> >
> > https://gist.github.com/anonymous/20c385bfbac1dfebffd648d88761274e
> >
> > Thanks.
> >
>
>


-- 
HD


More information about the graal-dev mailing list