To be fair, the length is not strictly 54 lines, since blocks of it depend on evaluation of the preprocessor (the #ifdef stuff). Still, that's pretty long. :)
54-line if condition in gcc's reload.c
11–20 of 95 posts
Re: 54-line if condition in gcc's reload.c
#12Trivia: This code is older than many of the readers. https://github.com/mirrors/gcc/blame/7057506456ba18f080679b2...
That's beautiful. It may be a monster, but it started so small in 1992 - then was grown with loving care in 1993, 1994, 1995, 1998, 1999, 2001, 2002, 2004, 2005, 2008, and 2011!
It was 16 lines in 1992. I guess that's not what it is today, but not exactly "so small". https://github.com/mirrors/gcc/blob/42c63e4d48cfac192be8c0cc...
The copyright notice goes back to '87. I wonder if '92 is just where the source control kicks in.
Re: 54-line if condition in gcc's reload.c
#13Why not break it up into variables or functions so that the logic can be followed while reducing the likelihood that a bug creeps in? What is the excuse for horrible code like this?
[deleted]
Re: 54-line if condition in gcc's reload.c
#14To be fair, the length is not strictly 54 lines, since blocks of it depend on evaluation of the preprocessor (the #ifdef stuff). Still, that's pretty long. :)
That makes it even worse.
Re: 54-line if condition in gcc's reload.c
#15Why put logical operator at the start and not the end of each line?
I.e., this style (used in this case)
&& (CONSTANT_P (SUBREG_REG (in))
|| GET_CODE (SUBREG_REG (in)) == PLUS
|| strict_low
|| (((REG_P (SUBREG_REG (in))
(CONSTANT_P (SUBREG_REG (in)) ||
GET_CODE (SUBREG_REG (in)) == PLUS ||
strict_low ||
(((REG_P (SUBREG_REG (in)) &&
More on topic, I don't see why keep such a big conditional and not move it out to its own function(s) (but this has been asked already in this thread).
Re: 54-line if condition in gcc's reload.c
#16To be fair, the length is not strictly 54 lines, since blocks of it depend on evaluation of the preprocessor (the #ifdef stuff). Still, that's pretty long. :)
You can count that as yet another condition. ;)
Re: 54-line if condition in gcc's reload.c
#17Trivia: This code is older than many of the readers. https://github.com/mirrors/gcc/blame/7057506456ba18f080679b2...
I'm impressed that the blame log has survived intact. What SCM was originally used?
Re: 54-line if condition in gcc's reload.c
#18Why not break it up into variables or functions so that the logic can be followed while reducing the likelihood that a bug creeps in? What is the excuse for horrible code like this?
It's been getting the job done for decades, in perhaps the most popular compiler of all time. I'm willing to trust the maintainers' judgement on this one. If they'd spent all their time needlessly fixing what ain't broke, gcc would've gone the way of GNU/Hurd.
That's an argument from survivorship. Just because they've been successful doesn't mean this code shouldn't be improved.
Re: 54-line if condition in gcc's reload.c
#19Why put logical operator at the start and not the end of each line? I.e., this style (used in this case) && (CONSTANT_P (SUBREG_REG (in)) || GET_CODE (SUBREG_REG (in)) == PLUS || strict_low || (((REG_P (SUBREG_REG (in)) versus this style: (CONSTANT_P (SUBREG_REG (in)) || GET_CODE (SUBREG_REG (in)) == PLUS || strict_low || (((REG_P (SUBREG_REG (in)) && I don't have a personal preference here, just looking for any prac…
Personally I find it easier to read the conditionals lined up in columns and with indentation on the left than at the end where they may or may not be lined up depending on the length of the expression.
Re: 54-line if condition in gcc's reload.c
#20I was going to take a crack at breaking this apart into component functions, but I realized that I don't know where to draw the lines, or what to name the functions, without understanding the internals of this part (and probably other parts) of the compiler.
And that's why this will be here forever.