On 06/25/14 03:36, Richard Sandiford wrote:
I think this is an example of another problem with gcc coding style:
that we're far too afraid of temporary variables. In David's scheme
I think this would be:
Historical coding style :( It's particularly bad in RTL land, but you
see the same problems in places like fold-const.
if (rtx_mem *mem = as_a <rtx_mem *> (XEXP (x, 0)))
*total = address_cost (XEXP (mem, 0), GET_MODE (mem),
MEM_ADDR_SPACE (mem), true);
which with members would become:
if (rtx_mem *mem = as_a <rtx_mem *> (...))
*total = address_cost (mem->address (), mem->mode (), mem->address_space
(),
true);
(although if we go down that route, I hope we can add an exception to the
formatting rule so that no space should be used before "()".)
There was some talk of revamping the rules of parens for member function
calls. I don't recall what the final outcome was.
I prefer the latter, but I tend to worry about making David's patches
even more invasive than they already are :-)
I suppose with the magic values it would be:
if (rtx_mem mem = as_a <rtx_mem> (x[0]))
*total = address_cost (mem[0], mem.mode (), mem.address_space (), true);
but I'm not sure that that would really be more readable.
Please, no...
But like you say, I'm not sure whether it would really be a win in the end.
I think what makes this example so hard to read is again that we refuse
to put XEXP (x, 0) in a temporary variable and just write it out in full
4 times instead.
if ((GET_CODE (op0) == SMAX || GET_CODE (op0) == SMIN)
&& CONST_INT_P (XEXP (op0, 1))
&& REG_P (XEXP (op0, 0))
&& CONST_INT_P (op1))
is a bit more obvious.
And probably faster as well since we've CSE'd the memory reference. In
this specific example it probably doesn't matter, but often there's a
call somewhere between XEXPs that we'd like to CSE that destroys our
ability to CSE away memory references.
This kind of problem is prevasive in the RTL analysis/optimizers.
