handling of Math intrinsics for multiple GPU targets

[Doug Simon]

This is obviously something else that needs to be vectored to each backend, allowing each to make their own decision as you say. It will be factored into the redesign currently going on. Please let us know of other abstractions like this that need to be broadened or exposed to each backend.

On Oct 8, 2013, at 6:11 PM, "Venkatachalam, Vasanth" <Vasanth.Venkatachalam at amd.com> wrote:

> Hi,
> 
> I noticed that Graal is building a superset of math intrinsics for the host runtime  (x86) and then filtering out some of these methods from being intrinsified based on the value of a config parameter (e.g., config.usePopCountIinstruction, config.useAESIntrinsics, etc.).
> 
> In more detail when the VM first starts up in VMToCompilerImpl.start() it gets the host runtime (which is x86) and builds a superset of intrinsics for that runtime by calling GraalMethodSubstitutions.registerReplacements( ). This in turn processes a class file MathSubstitutionsx86.class to get a list of math routines to be intrinsified, filters out some of these routines (via a call to HotSpotReplacementsImpl.registerMethodSubstitution()) and adds the remaining ones to a HashMap called registeredMethodSubstitutions.
> 
> For the case of supporting multiple GPU targets, it sounds like this logic is the reverse of what we need. Instead of building a superset of intrinsics for x86 and filtering them for the target runtime, we need a way for each target runtime (e.g., HSAIL) to specify its own list of supported intrinsics. Has anyone thought about how this should be handled?
> 
> Vasanth
> 
>