| |
| Posted by Walter Bright in reply to Manu | PermalinkReply |
|
Walter Bright
| On 9/11/2024 3:37 PM, Manu wrote:
> The rule that the code is laid out in the order the programmer wrote it makes
> the most sense to me. It gives the programmer the control over how it gets
> executed. The same applies to switch statements - put the most visited case
> statements first.
>
>
> This isn't a matter of opinion. The compilers do what the compilers do, and that's just the way it is.
As a matter of fact, not opinion, this is the way dmd works. How gdc/ldc work with this is up to Iain and Martin. I don't tell them what to do.
> I can't reproduce this claim of yours.
> I couldn't reproduce a case where your hack produced the code you say, and even if I could I would never accept it to be reliable.
Use the -O switch as I suggested and verified to work with gcc.
> ...and even if it DID work reliably, I /still/ wouldn't accept it, because mangling and contorting my code like that is just stupid.
I'm sympathetic to that viewpoint, and generally go for writing the clearest code as a priority. If I really need to micro-optimize a section, I'll write it in inline assembler rather than trying to convince a compiler to do it my way.
There's no guarantee any hints (like `register`) have any effect, either.
> ...and it's not like we're even talking about a trade-off here! An otherwise benign and extremely low-impact hint attribute on a control statement just isn't an edgy or risky move.
It's a complexity issue. The more complex the language, the fewer people will be interested in learning it. (I'm kind of amazed that newbies are still willing to learn C++ with the heft of its spec that literally nobody understands.) The more complex, the more risk of bugs. It is definitely not a low-impact hint. The intermediate code does not support it, such would need to be added in to all the code that deals with the block structure.
I know these things look simple on the surface, but they aren't. As more evidence of that, consider the linked article on what a mess happens when [[likely]] is used in a non-trivial manner.
|