handling of Math intrinsics for multiple GPU targets

Venkatachalam, Vasanth Vasanth.Venkatachalam at amd.com
Tue Oct 8 09:11:49 PDT 2013


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




More information about the graal-dev mailing list