On 10/01/2015 11:37 AM, Bernd Schmidt wrote:
On 09/29/2015 04:31 PM, James Greenhalgh wrote:
On the other side of the equation, we want a cost for the converted
sequence. We can build a cost of the generated rtl sequence, but for
targets like AArch64 this is going to be wildly off. AArch64 will expand
(a > b) ? x : y; as a set to the CC register, followed by a conditional
move based on the CC register. Consequently, where we have multiple sets
back to back we end up with:
set CC (a > b)
set x1 (CC ? x : y)
set CC (a > b)
set x2 (CC ? x : z)
set CC (a > b)
set x3 (CC ? x : k)
Which we know will be simplified later to:
set CC (a > b)
set x1 (CC ? x : y)
set x2 (CC ? x : z)
set x3 (CC ? x : k)
I guess the transformation you want to make is a bit unusual in that it
generates such extra instructions. rtx_cost has problems taking such
secondary considerations into account.
I haven't quite made up my mind about the new target hook, but I wonder
if it might be a good idea to try and simplify the above sequence on the
spot before calculating costs for it. (Incidentally, which pass removes
the extra CC sets?)
I don't know whether you've done any more work on the patch series, but
I think I've made up my mind that optimizing the sequence before
computing its cost would be a good thing to try first. Either with a
better expander interface which generates the right thing immediately,
or running something like cselib over the generated code. I think this
would give more reliable results rather than guesstimating a redundancy
factor in the cost function.
Bernd
