2018-05-21 03:13 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000458mercuryFeature Requestpublic2018-05-03 07:25
Reporterzs 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityN/A
StatusassignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000458: optimize unify and compare for packed arguments
DescriptionAt the moment, when unifying or comparing the arguments of two functors,
we extract each argument from each functor and unify/compare the corresponding
arguments individually.

If two or more arguments of a functor are packed together into a single word,
we could test whether they are *all* equal by testing whether the words are equal. (We always set all the unused bits to zeroes.)

For comparison, the situation is trickier, but there is still room for optimization.

First, we would need to change our allocation strategy. Our current strategy
of putting the first packed argument into the least significant bits and the
following arguments into more and more significant bits is exactly wrong
for comparing the packed arguments all at once: we would need to put
an earlier packed argument into more significant bits than a later argument
packed into the same word.

Second, even then we could compare a sequence of arguments packed
into a word by comparing the full word only if all the packed arguments
compare as unsigned values. If any of them are of type int{8,16,32}, then
those would have to compared separately. However, any contiguous subsequence
of unsigned arguments could and should be compared together.

The most complex part of this would be devising the right HLDS representation
of the operations that compare more than one argument at a time. Maybe we could
generate foreign proc goals for them.

Also note that this feature request somewhat modifies Mantis 0000446;
we should NOT fetch the arguments that are packed together into the same word
separately.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes
There are no notes attached to this issue.
+Notes

-Issue History
Date Modified Username Field Change
2018-05-03 07:24 zs New Issue
2018-05-03 07:25 zs Assigned To => zs
2018-05-03 07:25 zs Status new => assigned
+Issue History