61–70 of 95 posts
Earlier quoted context omitted.
Yes, yes it would have, there is literally no question about that. It also appears that some of the parts of the conditions are repeated, so those could have been refactored.
I'm sure a good optimizing compiler like GCC would optimize out repeated expressions in conditions ;) (perhaps not if they're declared volatile(?))
#ifdef should be shot
For the curious, reload was written by Richard Kenner, who, while a wonderful guy, was not generally familiar with modern compiler architecture (graph coloring register allocation goes back to 1982, reload was started in the late 80's). It essentially took the place of spill placement/code/legalization. Over the years, it grew rematerialization, instruction combination, copy coalescing, stack slot sharing and all sor…
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.
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…
...
== NO_REGS))And once you're doing that, might as well use them for the whole file.
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…
Earlier quoted context omitted.
You could say exactly the same about OpenSSL - it's not a good argument.
No. A bug in OpenSSL makes the thing meaningless while in GCC it affects some corner case. I want better vectorization.
If that corner case manifests as a bug in OpenSSL, it is by definition at least as bad as a bug in OpenSSL.
Earlier quoted context omitted.
Compilers are complex, and these conditionals had to be evaluated in some way. Sure the author could have split it up into multiple if statements, but would have that really helped?
`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.
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. 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 needless…
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.