On Wednesday, 14 January 2015 at 17:53:54 UTC, deadalnix wrote:
Once again, no specifics.
How is a bitmask (e.g. a set) not specific?
I was not lost. I know how to recognize a non sequitur when I
read one.
Then you should also be able to explain where you got lost.
1. A single branch on return.
2. Multiple return paths.
2a) returning to the calling function
2b) using a landing pad (current solution)
It's a good thing that you can do all of these in D already.
This is about what the compiler does, not what you can do in D.
So no. You cannot have multiple return paths (like returning to
the returnaddress+OFFSET) or branch implicitly based on the carry
flag upon return.
You only need this when you are using static TLS variable,
which is not that common in practice. The change would makes
this required all over the place.
That's the point. To have a buffer in TLS so that you don have to
do transient heap allocations (allocation directly followed by
deallocation of same object).
Making a new calling convention is not going to magically make
things faster. If the calling convention need to do more, it is
certainly going to make things slower.
One needs a calling convention to ensure that the backend puts
the exception signal in the right register or to do offset
return. Or to free up more registers. Haskell has a register
heavy calling convention to speed up Haskell code.
So it is not certainly going to make things slower. Clearing a
flag/register will most likely fill in a bubble in the pipeline.
A predicted non-branching branch instruction is fairly cheap.
Hopefully, function calls are not common at all, so that
shouldn't be a problem.
?
