This is a list of all comments for CR-1587.

Review Summary: No summary

General Comment by Doug Simon on 02 October 2013, 22:15 

  Waiting until after LIR generation is too late in compilation
  to choose the backend since LIR is already backend specific (as
  evidenced by the ISA specific subclasses of LIRGenerator).
  Ideally, the caller of {{GraalCompiler.compileGraph()}}
  contains the appropriate decision logic and simply passes in
  the required Backend object.
  
  Your sketch code implies that a VM will have at most one GPU
  backend. I can imagine it's possible (in the future?) to have
  very heterogeneous systems with multiple different GPUs
  available. In this case, I believe we should add support for
  this now. For example, in HotSpotGraalRuntime:
  {code}
  
      /**
       * Host backend which is the CPU the HotSpot C++ runtime is
  compiled for.
       */
      private final HotSpotBackend backend;
  
      /**
       * GPU (or even other CPU?) backends.
       */
      private final Map<String, HotSpotBackend> extraBackends;
  
      public HotSpotBackend getHostBackend() {
          return backend;
      }
  
      public HotSpotBackend getBackend(String name) {
          return extraBackends.get(name);
      }
  
      protected abstract HotSpotBackend createBackend();
      protected abstract Map<String, HotSpotBackend>
  createExtraBackends();
  
  {code}
  
  I'm not sure that String is the right data structure for a
  backend identifier but you get the idea. I think the best
  choice will become clearer the more we think about what the
  backend choosing logic looks like (and where it lives). This
  part is still very unclear to me.

General Comment by Thomas Wuerthinger on 02 October 2013, 22:22 

  We also should prepare for the case where from one compilation
  multiple different compilation results (for multiple backends)
  are produced.



---

ID: CR-1587 

Title: supporting and using multiple Backends within HotSpotGraalRuntime
Statement of Objectives:
This patch from Bharadwaj is a sketch of how we might better support extra backends in Graal. This patch should be evaluated in the context of the email reproduced below:

{code}
From: Bharadwaj Yadavalli <bharadwaj.yadavalli@oracle.com>
To: "DOUGLAS,SIMON" <doug.simon@oracle.com>, 
 Thomas Wuerthinger <thomas.wuerthinger@oracle.com>
Subject: Support for multiple backends in Graal

Hi Doug and Thomas,

As I get more familiar with the (basic?) Graal code, I am attempting to 
get rid of PTXHotSPotGraalRuntime that I introduced a few weeks ago.

My intent is to initialize and reference multiple HotSpotBackend 
instances in HotSpotGraalRuntime instance.

The model of code generation I am visualizing is as follows:

After LIR is generated, depending upon some (yet unclear) criteria, I 
would like to call emitCode in compileGraph() of GraalCompiler.java by 
passing the appropriate backend as its argument.

In other words,

if (decided-to-generate-CPU-code)
     emitCode(backed, .....); // as is done today
} else if (decided-to-generate-non-CPU-code) {
     emitCode(gpuBackend, ....); // appropriate emitCode method of 
PTX/HSAIL/Intel Phi etc is invoked
}

I placed a non-fucntional set of changes that I believe will illustrate 
what I am experimenting with at 
http://javaweb.us.oracle.com/~byadaval/rough-sketch.diff.

I would like to get your feedback on this proposed direction of mine to 
add support for multiple backends that are all "first-class citizens" 
and to invoke them.

Thanks,

Bharadwaj

P.S: I do not know of others in Graal team that might be able to provide 
feedback on this aspect. Feel free to forward or Cc them in you replies.
{code}

State: Review

Author: Doug Simon
Moderator: Doug Simon
Reviewers: (6 active, 0 completed*)
     Lukas Stadler
     Thomas Wuerthinger
     Gilles Duboscq
     Roland Schatz
     Bharadwaj Yadavalli
     Chris Thalinger