|
From: Florian K. <br...@ac...> - 2008-09-20 15:30:31
|
Hello,
I was looking at how to define a pattern for "add immediate"
which should match a subtree independent of whether the constant
is located in the first or second operand. Looking at irmatch
I see that it does not know about commutative operators.
So I'd have to define two patterns.. Hmm. I was trying to avoid
that.
VEX does not seem to guarantee that a constant is placed in
a defined operand position when the operator is commutative.
So I do need to consider both cases or accept that less efficient
code is generated.
How is this handled in other backends?
I was thinking of extending IRExpr_Binop to be aware of
commutative operators. What do you think of that approcach?
Florian
|
|
From: Julian S. <js...@ac...> - 2008-10-08 09:19:18
|
> VEX does not seem to guarantee that a constant is placed in > a defined operand position when the operator is commutative. True. > 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? FWIW, if you are trying to speed up a tool, the most effective approach is to tune the tool itself. That tends to be where most of the time goes. Especially if the tool is managing large data structures and thereby causing a large amount of D1/L2 pollution compared to the original program. J |
|
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 |