Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

54-line if condition in gcc's reload.c

github.com

Post reply on HN
Print view View original

81–90 of 95 posts

Re: 54-line if condition in gcc's reload.c

#81

Post by raldi »

matthewmacleod wrote: post #32
raldi wrote: post #10

Earlier quoted context omitted.

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.

You could say exactly the same about OpenSSL - it's not a good argument.

You're assuming and implying that this code is more bug-prone in its current state than it would be if it were rewritten.

I'm not convinced that's true.

Re: 54-line if condition in gcc's reload.c

#82

Post by frevd »

goblin89 wrote: post #15

Why 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…

for copy&pasting around this is very practical, also with arrays:

$moo =
[
    a

  , b

  , d


];
// insert c

better than having the delimiter at the end, where you a) have to take care where you relocate the last element and b) could forget to remove it at the last element (most language parsers tolerate that though).

Re: 54-line if condition in gcc's reload.c

#83

Post by klibertp »

shawnz wrote: post #75
drglitch wrote: post #55

Earlier quoted context omitted.

It is also easier to comment out lines of code if you need to test something. This is especially useful in SQL, where you can quickly -- a condition or a column, without editing commas etc on other lines, eg SELECT some_col , another_col --, and_another , and_more FROM blah EDIT: too bad formatting is screwed up :/

Isn't this behaviour exactly the same as with commas at the end? Here, to comment out the first line you would need to edit the second. With commas at the end, to comment out the last line you would need to edit the second last. Other than that, no editing of other lines is required. In fact, in a language like Javascript where extra trailing commas are allowed, it seems that this argument makes even more sense for c…

Trailing comma in SQL is a syntax error. It's also not allowed in JSON. And editing second last line can be a pain if you're testing something and are commenting/uncommenting the last line repeatedly.

Re: 54-line if condition in gcc's reload.c

#84

Post by GnarfGnarf »

I will never have the skills to maintain let alone write a compiler. However, in a situation like this, I would break up the condition into a set of sub-conditions, set intermediate booleans, and progressively build upon the condition tests so as to make the code more intelligible and maintainable. No need for additional functions.

(Amusing incongruity: "boolean" fails the spellchecker in an IT forum :o)

Re: 54-line if condition in gcc's reload.c

#85

Post by tptacek »

rayiner wrote: post #77
probably_wrong wrote: post #63

Earlier quoted context omitted.

As someone moderately curious, I hope I'm not the only one when I say: I didn't understand a word after "the late 80's". And that's only because I searched for "graph coloring register allocation" first.

For simplicity, a compiler manipulates an internal representation in terms of virtual registers. A register allocator assigns physical registers to these virtual ones, under the principle that different virtual registers may be assigned to the same physical one if they are not live (I.e. hold a value that will be used in the future) at the same time. Spill code generation is necessary because at a program point, ther…

Thanks everyone for watching another exciting episode of "Two Lawyers Explain Compiler Theory". :)

Re: 54-line if condition in gcc's reload.c

#86

Post by valarauca1 »

GnarfGnarf wrote: post #84

I will never have the skills to maintain let alone write a compiler. However, in a situation like this, I would break up the condition into a set of sub-conditions, set intermediate booleans, and progressively build upon the condition tests so as to make the code more intelligible and maintainable. No need for additional functions. (Amusing incongruity: "boolean" fails the spellchecker in an IT forum :o)

>booleans

C doesn't support native booleans, C99 does-ish. And you can hack it in with

    #typedef enum {false, true} bool;
C uses ints, all the way down, for everything, until you hit turtles.

Re: 54-line if condition in gcc's reload.c

#87

Post by fennecfoxen »

jblow wrote: post #68
frozenport wrote: post #60

Earlier quoted context omitted.

`if` statements are for the 80s, we live in in the 90s and have objects, inheritance and C++. The conditions can be implicit in the objects.

I don't even.

A qualified defense of the grandparent post.

In a lot of software in the industry I've seen, I'd say he's right -- instead of an "if X condition, do X code, if U condition, do Y, otherwise do Z" you can make an object, subclass the object's base class into a default type doing Z and two other types that do X and Y instead. (If you need to share more behaviors in a more complicated setup, you make the strategies into classes as well, then have the X1 and X2 classes invoke the X strategy.) Happiness ensues! (unless you're stuck with too much ugly-looking Java boilerplate or insane C++ templatization angle-brackets)

That said...

any good advice like that should be taken with a MASSIVE grain of salt because of the exigencies of real software development, especially software like gcc. Moreover the approach is not a panacea against code complexity because sometimes the relationships between different types of conditions are just plain complicated, as appears to be the case here.

So I can totally understand where this code is coming from, and while I can imagine it being far more elegant, it's not really the prime candidate for a rant. Grandparent post should chill out.

Re: 54-line if condition in gcc's reload.c

#88

Post by wglb »

This reminds me of a comment in a particularly hairy section of code in the MWC 8086 compiler written by dgc (among other things, author of MicroEmacs). I don't have the exact wording but it was something to the effect of

I am frankly embarrassed by the number of bugs that have been tracked to this function.

This was in the day before register coloring.

Earlier, I had the chance to write a code generator for an implementation language targeting the 8085 (!) and even that was sufficiently hairy that the team that took it over complained about the difficulty of improving the code.

[Edit] Time sequence correction.

Re: 54-line if condition in gcc's reload.c

#89

Post by chillingeffect »

userbinator wrote: post #59

The rest of that file also has a ton of redundancies and verboseness its in logic that could be simplified considerably; e.g. I see this pattern a lot (428 ~ 435): x && y || !x && z In this absence of side-effects, this basically implements a 2-input multiplexer and is identical to x ? y : z In the 54-line condition the first obvious thing I'd factor out is SUBREG_REG(in) and GET_MODE(SUBREG_REG(in)), and then work o…

I find "inmp > msrirp;" way more readable than "inmpgtmsrirp".

The same goes for "GET_MODE_PRECISION(msrirp)" which was replaced with "msrirp."

Re: 54-line if condition in gcc's reload.c

#90

Post by LukeShu »

asveikau wrote: post #12
mrspeaker wrote: post #7

Earlier quoted context omitted.

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.

I thinks that's just when the source control kicks in.

DannyBee claims that reload was started in the late 80s.

There are commits going back to 1988, but it looks like a lot of the early commits are out of order; the repository was (at least) converted from RCS to CVS to SVN to Git.

Post reply on HN