[PATCH] 8147527: Non-optimal code generated for postfix unary operators

[bsrbnd]

Hi,

Consider the following example slightly modified from issue 8147527
description to incorporate an assignment operator and an inner class
which are both of them involved in the optimization process:

class Issue8147527 {
    Integer i=0;
    private Integer test() {
        this.i += 3;
        for (; i<5; this.i++);
        return this.i++;
    }

    Integer j=10;
    class Inner {
        private Integer test() {
            return Issue8147527.this.j++;
        }
    }

    public static void main(String[] args) {
        Issue8147527 self = new Issue8147527();
        System.out.println(self.test());
        System.out.println(self.i);

        Inner in = self.new Inner();
        System.out.println(in.test());
        System.out.println(self.j);
    }
}

The following patch omits "this" for the special case of a
select-expression used as an lvalue.
Thus we had before optimization:

  private java.lang.Integer test();
    Code:
       0: aload_0
       1: astore_1
       2: aload_1
       3: aload_1
       4: getfield      #3                  // Field i:Ljava/lang/Integer;
       7: invokevirtual #5                  // Method
java/lang/Integer.intValue:()I
      10: iconst_3
      11: iadd
      12: invokestatic  #2                  // Method
java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      15: dup_x1
      16: putfield      #3                  // Field i:Ljava/lang/Integer;

And after optimization, we have:

  private java.lang.Integer test();
    Code:
       0: aload_0
       1: aload_0
       2: getfield      #3                  // Field i:Ljava/lang/Integer;
       5: invokevirtual #5                  // Method
java/lang/Integer.intValue:()I
       8: iconst_3
       9: iadd
      10: invokestatic  #2                  // Method
java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
      13: putfield      #3                  // Field i:Ljava/lang/Integer;

I've run all javac tests and it seems quite good.
Notice that I haven't checked the "super" case yet, waiting for any
feedback about the first optimization.

Regards,
Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
@@ -2253,6 +2253,7 @@
         case SELECT: {
             final JCFieldAccess s = (JCFieldAccess)lval;
             Symbol lid = TreeInfo.symbol(s.selected);
+            if (lid != null && lid.name.equals(names._this)) return
builder.build(make.Ident(s.sym));
             if (lid != null && lid.kind == TYP) return builder.build(lval);
             return abstractRval(s.selected, new TreeBuilder() {
                     public JCExpression build(final JCExpression selected) {