public abstract class FloatValueProfile extends Profile
Specialized value profile to capture certain properties of float runtime values.
Value profiles require a runtime check in their initialized state to verify their profiled
assumption. Value profiles are limited to capture monomorphic profiles only. This means that if
two or more values are profiled within a single profile then the profile has no effect. If the
value assumption is invalidated in compiled code then it is invalidated.
Usage example:
class SampleNode extends Node {
final FloatValueProfile profile = FloatValueProfile.createRawIdentityProfile();
float execute(float input) {
float profiledValue = profile.profile(input);
// compiler may know now more about profiledValue
return profiledValue;
}
}
A profile is a Truffle utility class that uses the Truffle compiler
directives to guard for and/or forward runtime information to the compiler.
Usage: Profiles should be stored in final or compilation final fields of node classes to ensure that they can get optimized properly.
Profiles must not be shared between ASTs. Using the same profile multiple times in a single
node or in multiple nodes which link to the
same root is allowed. Never store profiles inside runtime values that
leave the scope of the originating AST. This limitation exists because the used mechanism to
invalidate compiled code performs local invalidations only. For global speculations use
assumptions instead.
Compilation: Some profiles like branch profiles do not induce
additional overhead in compiled code. Others like value profiles might
require a runtime check to verify their assumptions which are forwarded to the compiler. Even if
profiles do not induce direct overhead in compiled code it still might get invalidated as a
result of using profiles. Invalidating profiles will result in the invalidation of compiled code.
It is therefore essential to place these profiles in way that is neither too aggressive nor too
conservative.
Footprint: Whether profiling information can be forwarded to the compiler depends on the
capabilities of the runtime system. If the runtime returns
true in TruffleRuntime.isProfilingEnabled() then runtime information will
get collected. This comes at at the cost of additional overhead and footprint in interpreted
mode. Thats why the factory methods of profiles can return implementations where profiling is
disabled. Using disabled profiles makes sense for runtimes that are unable to use the collected
profiling information. Even runtime implementations that are able to use this information might
decide to turn off profiling for benchmarking purposes.
Profile subclasses:
BranchProfile to profile on unlikely branches like errors.ConditionProfile to profile on conditionals or boolean values.LoopConditionProfile to profile on conditionals of loops with special support for
counted loops.ValueProfile to profile on properties like type and identity of values.ByteValueProfile to profile on byte values.IntValueProfile to profile on int values.LongValueProfile to profile on long values.FloatValueProfile to profile on float values.DoubleValueProfile to profile on double values.PrimitiveValueProfile to profile on objects by identity and on primitives by value.
FloatValueProfile.createRawIdentityProfile(),
ValueProfile| Modifier and Type | Method and Description |
|---|---|
static FloatValueProfile |
createRawIdentityProfile()
Returns a value profile that profiles the exact value of a
float using
Float.floatToRawIntBits(float). |
static FloatValueProfile |
getUncached()
Returns the uncached version of the profile.
|
abstract float |
profile(float value) |
clonepublic abstract float profile(float value)
public static FloatValueProfile createRawIdentityProfile()
float using
Float.floatToRawIntBits(float).IntValueProfilepublic static FloatValueProfile getUncached()