View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0000446 | mercury | Feature Request | public | 2018-01-30 02:32 | 2018-01-30 02:32 | ||||||||
Reporter | zs | ||||||||||||
Assigned To | zs | ||||||||||||
Priority | low | Severity | feature | Reproducibility | N/A | ||||||||
Status | assigned | Resolution | open | ||||||||||
Product Version | |||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0000446: smarter comparisons of structures | ||||||||||||
Description | The code we automatically generate two compare structures such as f(int, int, ..., int) looks like this: X = f(X1, X2, ..., Xn), Y = f(Y1, Y2, ..., Yn), ( if compare(R1, X1, Y), R1 != "=" then R = R1 else if compare(R2, X2, Y2), R2 != "=" then R = R2 ... ) The problem with this is that we execute the code to retrieve X2 ... Xn and Y2 ... Yn even if X1 != X2. We should instead generate code that picks up the value of Xi and Yi just before we call compare on them, in the condition of the relevant if-then-else. If the comparison of Xi and Yi is quick (such as when they are integers), then the heap cells of X and Y should still be in the cache. If the comparison is NOT quick, such as when Xi and Yi are complex data structures, having to pick up Xi+1 and Yi+1 from the heap may add an extra cache miss. We should experiment with storing Xi+1 and Yi+1 in the stack frame in such cases (and in such cases *only*). That may pay back if Xi = Yi, but would be a cost if Xi != Yi (since in that case we won't need to compare Xi+1 and Yi+1). The same considerations apply to unify predicates. | ||||||||||||
Additional Information | We should test whether, and if so how well, the stack_opt optimization can do this task already. | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files |
|