Pedro Alves schrieb:
On Friday 14 October 2011 18:19:00, Georg-Johann Lay wrote:

Paolo Bonzini schrieb:

On 10/14/2011 06:23 PM, Georg-Johann Lay wrote:

+@item -mjump-to-noreturn
+@opindex mjump-to-noreturn
+Use a jump instruction instead of a call instruction when calling a
+no-return functions.  This option is active if optimization is turned
+on and just affects the way a call instruction is printed out.
+Besides that, it has no effect on code generation or debug information.

I think this is not really accurate given Richard's input.

Confused.  The conclusion was to introduce a new command line option in order
to have individual control over this feature.  The option is named
-mjump-to-noreturn now instead of -mjump-noreturn. Is that what you mean?

My 2c.  You've used implementor-speak to describe the option, while you
should use user-speak.  Mention that it saves stack, but the downside is
that it affects backtracing (and suggest turning it off if you want to
backtrace out of abort, etc.).  Lose the "just affects the way a call
instruction is printed out" bit -- what's "printed out"?, a user
would ask.  Some users aren't even aware there's a separate assembler
that munches text is involved.

Thanks for your input. I am always grateful for hints on how to improve my english.

I'd also suggest renaming the option to `-mallow-tailcall-noreturn'
or `-mtailcall-noreturn' so that its spelling and description could
be more easily shared with other targets (and perhaps promoted
as -f option).

Looking at -foptimize-sibling-calls there is just

-foptimize-sibling-calls
        Optimize sibling and tail recursive calls.

        Enabled at levels -O2, -O3, -Os.

so the new option could be

-moptimize-noreturn-calls
        Optimize noreturn calls.  This might make debugging harder but
        will save storing the return address when calling roreturn
        functions.

        Enabled at levels -O2, -O3, -Os.

But the "makes debugging harder" clause is true for almost any optimization available, so should this tautology be mentioned along with each optimization that makes debugging harder?

Or simply like this:

-moptimize-noreturn-calls
        Optimize noreturn calls.

        Enabled at levels -O2, -O3, -Os.

What about the -moptimize-noreturn-calls in analogy to -foptimize-sibling-calls? Sound good to me.

Johann

Reply via email to