|
From: Florian K. <br...@ac...> - 2008-10-09 17:00:01
|
On Wednesday 08 October 2008 05:03:27 Julian Seward wrote: > > > I was thinking of extending IRExpr_Binop to be aware of > > commutative operators. What do you think of that approcach? > > Overall, I'd say that fine tuning the instruction selectors > produces changes in performance which are so small as to often be > almost unmeasurable. I did a round of isel tuning before the > release of 3.2.0. For Memcheck running large programs it > would be often in the region of a 1% change. Do you have evidence > from a run with --profile-flags=10001100 that such bad cases > are happening a lot? > I am not trying to speed up the tool. I'm working on a new backend and noticed a pattern of load immediate followed by addition when I began looking at the code emitted by VEX. From comments I've seen in the code it seems that the x86 and ppc backends also expect literal values in the right operand of commutative ops. So I think that moving constants into the subtree they are expected to be in is a beneficial transform. It's cheap if we candetect applicable contexts easily and a low hanging fruit to squeeze some cycles. I had thought about encoding the commutativity of operations in the values of the IROp enumerators. I've read the comment about the ordering of these enumerators but the magic value of Iop_INVALID suggests that there might be other assumptions the code makes about those values. Could you provide some insights? Alternatively, commutative operators could be grouped together so testing that property becomes a range check. I'd be willing to cook up a patch if you're interested. Florian |