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: Request for testing on fold-const.c patch


>   	  return (operand_equal_p (TREE_OPERAND (arg0, 0),
>   				   TREE_OPERAND (arg1, 0), flags)
>   		  && operand_equal_p (TREE_OPERAND (arg0, 1),
>   				      TREE_OPERAND (arg1, 1), flags)
> ! 		  && ((!TREE_OPERAND (arg0, 2) || !TREE_OPERAND (arg1, 2))
> ! 		      ? TREE_OPERAND (arg0, 2) == TREE_OPERAND (arg1, 2)
> ! 		      : operand_equal_p (TREE_OPERAND (arg0, 2),
> ! 					 TREE_OPERAND (arg1, 2), flags))
> ! 		  && ((!TREE_OPERAND (arg0, 3) || !TREE_OPERAND (arg1, 3))
> ! 		      ? TREE_OPERAND (arg0, 3) == TREE_OPERAND (arg1, 3)
> ! 		      : operand_equal_p (TREE_OPERAND (arg0, 3),
> ! 					 TREE_OPERAND (arg1, 3), flags)));

    Does this expression not strike you as excessively long?

It's far from my record. ;-)

Seriously, though, I consider this sort of thing far cleaner than the
alternative approach where you break it up into separate return statements by
inverting the conditions.  In this case, that would be:

	if (!operand_equal_p (TREE_OPERAND (arg0, 0),
  			      TREE_OPERAND (arg1, 0), flags))
          return 0;

	if (!operand_equal_p (TREE_OPERAND (arg0, 1),
   			      TREE_OPERAND (arg1, 1), flags))
	  return 0;


	if ((!TREE_OPERAND (arg0, 2) || !TREE_OPERAND (arg1, 2))
            ? TREE_OPERAND (arg0, 2) != TREE_OPERAND (arg1, 2)
            : operand_equal_p (TREE_OPERAND (arg0, 2),
 			       TREE_OPERAND (arg1, 2), flags))
	  return 0;

	return ((!TREE_OPERAND (arg0, 3) || !TREE_OPERAND (arg1, 3))
 		? TREE_OPERAND (arg0, 3) == TREE_OPERAND (arg1, 3)
 		: operand_equal_p (TREE_OPERAND (arg0, 3),
				   TREE_OPERAND (arg1, 3), flags));

I find the former *much* cleared because it puts everything related together
in one place while the latter distributes it over many lines.

Since most people look at code on the screen and not on paper, I find that
being able to put all related code in one screen-full is very important for
readability and often worth slightly compromising other cleanliness goals
to accomplish.


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