X10

Support compilation with Intel C++ compiler

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: X10 2.2
  • Fix Version/s: X10 2.4
  • Component/s: Native X10: Compiler Codegen
  • Labels:
    None
  • Number of attachments :
    0

Description

Native X10 can not currently be compiled from source using the Intel C++ compiler (icc) due to compatibility problems with some of the generated code.

The main problem seems to be around statement expressions:

icpc -DNO_TRACING -DNO_CHECKS -O2 -finline-functions -pthread -DX10_USE_BDWGC -I. -I../x10rt/include -I"./bdwgc/install/include" -Igen -ansi -pedantic -Wall -Wextra -Wno-long-long -Wno-unused-parameter -shared -fPIC -c x10aux/assert.cc -o x10aux/assert.o
     [exec] gen/x10/lang/IntRange.h(113): error: destructible entities are not allowed inside of a statement expression
     [exec]           return (__extension__ ({

This is a known compatibility issue with GNU statement expressions and icc http://software.intel.com/en-us/articles/cdiag1487/ and doesn't appear likely to be fixed.

How difficult is it to avoid the use of this sort of statement expression? In this particular case, the statement expression:

    x10::lang::IntRange __plus(x10_int i) {
        
        //#line 52 "/scratch/x10-trunk/x10.runtime/src-x10/x10/lang/IntRange.x10": x10.ast.X10Return_c
        return (__extension__ ({
                x10::lang::IntRange alloc53335 =  x10::lang::IntRange::_alloc();
                // ... inlined constructor body
                alloc53335;
        }))
        ;
    }

could probably be replaced with

    x10::lang::IntRange __plus(x10_int i) {
        x10_int min_ = ((x10_int) (((*this)->FMGL(min)) + (i)));
        x10_int max_ = ((x10_int) (((*this)->FMGL(max)) + (i)));
        x10::lang::IntRange ret_; 
        ret_->_constructor(min_, max_);
        return ret_;
    }

However this is a simple case, so it may not be easy to generalise it for all applications.

Issue Links

is related to

New Feature - A new feature of the product, which has yet to be developed. XTENLANG-1891 Support building X10 on IA64/Linux

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Josh Milthorpe added a comment -

libatomic_ops (mentioned in XTENLANG-1891) is also a problem as some symbols it uses are not defined with icc. However this is really a problem for building BDWGC, which is not part of X10. It is possible to compile BDWGC separately using gcc.

Show
Josh Milthorpe added a comment - libatomic_ops (mentioned in XTENLANG-1891 ) is also a problem as some symbols it uses are not defined with icc. However this is really a problem for building BDWGC, which is not part of X10. It is possible to compile BDWGC separately using gcc.
Hide
Permalink
Igor Peshansky added a comment - - edited

Statement expressions resulting from inlining (X10-level statement expression AST nodes) can easily be eliminated by applying expression flattening. However, the C++ backend uses statement expressions in some other contexts, and those may not be so easy to handle.

Try building with -FLATTEN_EXPRESSIONS=true and see how many problems remain. You could also try -ALLOW_STATEMENT_EXPRESSIONS=false (but that may be out of date and may not produce fully functional code).

Show
Igor Peshansky added a comment - - edited Statement expressions resulting from inlining (X10-level statement expression AST nodes) can easily be eliminated by applying expression flattening. However, the C++ backend uses statement expressions in some other contexts, and those may not be so easy to handle. Try building with -FLATTEN_EXPRESSIONS=true and see how many problems remain. You could also try -ALLOW_STATEMENT_EXPRESSIONS=false (but that may be out of date and may not produce fully functional code).
Hide
Permalink
David Grove added a comment -

I've cleaned up some C++ codegen bugs related to expression flattening and I can build the runtime with FLATTEN_EXPRESSIONS=true and typical sample programs run correctly. That should get rid of all the statement expressions injected by inlining.

The only other place I see that the C++ backend is using statement expressions is in the codegen for Tuple_c (array literals). We probably should expand this earlier instead of leaving it as a complex operation all the way to codegen.

Show
David Grove added a comment - I've cleaned up some C++ codegen bugs related to expression flattening and I can build the runtime with FLATTEN_EXPRESSIONS=true and typical sample programs run correctly. That should get rid of all the statement expressions injected by inlining. The only other place I see that the C++ backend is using statement expressions is in the codegen for Tuple_c (array literals). We probably should expand this earlier instead of leaving it as a complex operation all the way to codegen.
Hide
Permalink
Igor Peshansky added a comment -

Right. We used to play games with varargs for primitive tuples, which was not expressible in the source language. We decided not to do that anymore a while ago, so we instead generated explicit element assignments in a loop. E.g., the current generated code for [1,2,3] is:

(__extension__({
    x10aux::ref<x10::array::Array<x10_int> > tmp0(x10::array::Array<x10_int>::_make(3));
    tmp0->__set(0, (x10_int)1);
    tmp0->__set(1, (x10_int)2);
    tmp0->__set(2, (x10_int)3);
    tmp0;
}))

The statement expression is needed for the multiple assignments given the current Array API.

The above corresponds to the source-level (well, AST-level) construct

({
    val tmp0 = new x10.array.Array(3);
    tmp0(0) = 1;
    tmp0(1) = 2;
    tmp0(2) = 3;
    tmp0
})

which we can generate before doing expression flattening (the Lowerer seems like a natural place for this, but I'm not sure it is done early enough).

We can also fix this by adding a private setAndReturnThis() method to the Array API that we can then use to generate a chain of calls, namely

class Array {
    ...
    private Array setAndReturnThis(i:Int, v:T) { this(i) = v; return this; }
    ...
}
...
new x10.array.Array(3).setAndReturnThis(0, 1).setAndReturnThis(1, 2).setAndReturnThis(2, 3)

which would completely get rid of statement expressions for array literals.

Show
Igor Peshansky added a comment - Right. We used to play games with varargs for primitive tuples, which was not expressible in the source language. We decided not to do that anymore a while ago, so we instead generated explicit element assignments in a loop. E.g., the current generated code for [1,2,3] is: (__extension__({ x10aux::ref<x10::array::Array<x10_int> > tmp0(x10::array::Array<x10_int>::_make(3)); tmp0->__set(0, (x10_int)1); tmp0->__set(1, (x10_int)2); tmp0->__set(2, (x10_int)3); tmp0; })) The statement expression is needed for the multiple assignments given the current Array API. The above corresponds to the source-level (well, AST-level) construct ({ val tmp0 = new x10.array.Array(3); tmp0(0) = 1; tmp0(1) = 2; tmp0(2) = 3; tmp0 }) which we can generate before doing expression flattening (the Lowerer seems like a natural place for this, but I'm not sure it is done early enough). We can also fix this by adding a private setAndReturnThis() method to the Array API that we can then use to generate a chain of calls, namely class Array { ... private Array setAndReturnThis(i:Int, v:T) { this (i) = v; return this ; } ... } ... new x10.array.Array(3).setAndReturnThis(0, 1).setAndReturnThis(1, 2).setAndReturnThis(2, 3) which would completely get rid of statement expressions for array literals.

People

  • Assignee:
    David Grove
    Reporter:
    Josh Milthorpe
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: