4 ms·

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

by dokem 12y ago

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

raldi 12y ago
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.
- rdwallis 12y ago
  That's an argument from survivorship. Just because they've been successful doesn't mean this code shouldn't be improved.
- matthewmacleod 12y ago
  You could say exactly the same about OpenSSL - it's not a good argument.
  - frozenport 12y ago
    No. A bug in OpenSSL makes the thing meaningless while in GCC it affects some corner case. I want better vectorization.
    - MaulingMonkey 12y ago
      > while in GCC it affects some corner case If that corner case manifests as a bug in OpenSSL, it is by definition at least as bad as a bug in OpenSSL.
  - raldi 12y ago
    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.
- MaulingMonkey 12y ago
  > 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. I don't trust anyone - myself included - writing code 1/10th as convoluted, age-of-product be damned. Code is not wine, old doesn't mean good. Neither do the maintainers, methinks: Looking at blame shows some refactoring. > If they'd spent all their time needlessly refactoring, gcc would've gone the way of GNU/Hurd. And the lack of needful refactoring may very well send it the way of COBOL - with everyone merely wishing it had gone the way of GNU/Hurd. I've seen clang and LLVM replace gcc in both of my vendor toolchains that used gcc - suggesting they've already wished and then done something about that wish. (Either that or licensing, but code like this stomps on the scales a bit...)
  - richardwhiuk 12y ago
    Old code is better - it's got bug fixes.
    - MaulingMonkey 12y ago
      > Old code is better - it's got bug fixes. It's also got prototypes that made it into production, ball of mud designs that encourage usage bugs, and C++ thrown together by that short lived intern who took a few Java classes, wrote everything assuming there was a garbage collector around, and took great care to avoid class trees with less than 3 layers of inheritance lest he be shamed for lack of 1337ness... then topped it off with a few __try/__catch blocks to deal with that one rare crash that nobody could find a repro case for. Re-implementing bug fixes is a toll... sometimes a very worthwhile one, though.
      - qu4z-2 12y ago
        To be fair, new code frequently has those attributes too.
  - mackal 12y ago
    If you've read some of the other posts, this whole file will hopefully be removed sometime in the future. For x86/x86_64 this file isn't of any use. Edit: also reading the wiki, they are fully aware how bad this code is.
- snogglethorpe 12y ago
  The problem of course, is that although reload very typically would work pretty well for the existing supported architectures (and optimizations etc), porting to a new architecture or changing other algorithms in the compiler would often expose problems that required extremely painful tweaking of the mess of unstated assumptions in the giant code hairball that is (was) reload... >< LRA is by all appearances infinitely more maintainable.
deleted 12y ago
[deleted]
tempestn 12y ago
Because the choice is never, "Should I refactor this code or not?" The choice is, "Should I refactor this code, or work on this feature/bug/refactoring/etc. instead?" Sure it could be refactored to be cleaner, but thus far, presumably there has always been something more important to do. Any time this if statement has been edited, it was clearly faster to simply add to the existing one than to refactor the whole thing. Sometimes it makes sense to take that extra time to refactor code when you happen to be working on it anyway... and sometimes there's something else more pressing to do.

by dokem 12y ago

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

raldi 12y ago

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.

rdwallis 12y ago
That's an argument from survivorship. Just because they've been successful doesn't mean this code shouldn't be improved.
matthewmacleod 12y ago
You could say exactly the same about OpenSSL - it's not a good argument.
- frozenport 12y ago
  No. A bug in OpenSSL makes the thing meaningless while in GCC it affects some corner case. I want better vectorization.
  - MaulingMonkey 12y ago
    > while in GCC it affects some corner case If that corner case manifests as a bug in OpenSSL, it is by definition at least as bad as a bug in OpenSSL.
- raldi 12y ago
  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.
MaulingMonkey 12y ago
> 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. I don't trust anyone - myself included - writing code 1/10th as convoluted, age-of-product be damned. Code is not wine, old doesn't mean good. Neither do the maintainers, methinks: Looking at blame shows some refactoring. > If they'd spent all their time needlessly refactoring, gcc would've gone the way of GNU/Hurd. And the lack of needful refactoring may very well send it the way of COBOL - with everyone merely wishing it had gone the way of GNU/Hurd. I've seen clang and LLVM replace gcc in both of my vendor toolchains that used gcc - suggesting they've already wished and then done something about that wish. (Either that or licensing, but code like this stomps on the scales a bit...)
- richardwhiuk 12y ago
  Old code is better - it's got bug fixes.
  - MaulingMonkey 12y ago
    > Old code is better - it's got bug fixes. It's also got prototypes that made it into production, ball of mud designs that encourage usage bugs, and C++ thrown together by that short lived intern who took a few Java classes, wrote everything assuming there was a garbage collector around, and took great care to avoid class trees with less than 3 layers of inheritance lest he be shamed for lack of 1337ness... then topped it off with a few __try/__catch blocks to deal with that one rare crash that nobody could find a repro case for. Re-implementing bug fixes is a toll... sometimes a very worthwhile one, though.
    - qu4z-2 12y ago
      To be fair, new code frequently has those attributes too.
- mackal 12y ago
  If you've read some of the other posts, this whole file will hopefully be removed sometime in the future. For x86/x86_64 this file isn't of any use. Edit: also reading the wiki, they are fully aware how bad this code is.
snogglethorpe 12y ago
The problem of course, is that although reload very typically would work pretty well for the existing supported architectures (and optimizations etc), porting to a new architecture or changing other algorithms in the compiler would often expose problems that required extremely painful tweaking of the mess of unstated assumptions in the giant code hairball that is (was) reload... >< LRA is by all appearances infinitely more maintainable.

deleted 12y ago

[deleted]

tempestn 12y ago

Because the choice is never, "Should I refactor this code or not?" The choice is, "Should I refactor this code, or work on this feature/bug/refactoring/etc. instead?" Sure it could be refactored to be cleaner, but thus far, presumably there has always been something more important to do. Any time this if statement has been edited, it was clearly faster to simply add to the existing one than to refactor the whole thing. Sometimes it makes sense to take that extra time to refactor code when you happen to be working on it anyway... and sometimes there's something else more pressing to do.