This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]