This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][4.3] Deprecate -ftrapv


> The code with conditional jumps is bigger but less dependant on the 
> OS environment or of any user code trying to install its own signal 
> handlers (especially for SIGSEGV which multiplexes so many exception
> causes). The performance impact is probably small since the jumps
> will normally be correctly predicted as not taken.

If you generate

	jo 1f
	int xxx
1: 

then it will normally default as predicted unless the CPU has dynamic 
information. This means you would get a branch misprediction first,
which is bad.

If you want to generate statically predicted branches you
would need to generate

	jno 1

	...

	ret
1: 	int xxx

with out-of-line int xxx. But with that it might be difficult to actually
find the original instruction pointer. e.g. the out of line label
cannot actually be in a cold section because dwarf2 cannot express that.
And even if it's in the same section as the rest of the function the
code flow might be hard to decipher afterwards.

e.g. I assume you would want to run C++ exception handlers
when this happens and for that surely the unwinder needs the original
IP as a starting point, doesn't it?

I think you would need to generate something like

0:
	jno 1

	...

	ret
1:	lea 0b(%rip),%rdi
	jmp overflow_abort

for each occurrence which would be quite a bit larger. 

-Andi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]