3 ms·

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 t

by 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.

by raldi 12y ago

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.