Chris would like to turn on -enable-eh rather than -enable-correct-eh-support in the llvm testsuite for those targets that support it. The following patch is intended to turn it on for x86 and ppc. Anton, Duncan, are you OK with this?
mf.patch (669 Bytes)
Hi Dale,
Chris would like to turn on -enable-eh rather than -enable-correct-eh-
support in the llvm testsuite for those targets that support it. The
following patch is intended to turn it on for x86 and ppc. Anton,
Duncan, are you OK with this?
yes, though see below.
Chris would also like to discuss renaming the EH command line
options, and I have to agree it's not obvious what they do.
He had a couple of ideas:> rename -enable-correct-eh-support to -enable-sjlj-exceptions or
> something> Maybe a better interface would be -eh-model={sjlj,dwarf,none} with
> none being the default?If these were visible to end users I would not like exposing sjlj, an
implementation detail; however my understanding is that they aren't.
On the basis that they're intended for use by llvm geeks, I think
either of these is an improvement, except in the second case I think
the default should be target-dependent. Comments?
How about having -enable-eh turn on dwarf eh on all targets (including
those that don't support it, in which case intrinsics get lowered to
nothing much IIRC), and also have it cause a LowerInvoke pass to be run
on targets that do not support dwarf eh. Since LowerInvoke can result
in costly code, add a -disable-eh-emulation option (more or less
equivalent to the opposite of -enable-correct-eh-support) which causes
the LowerInvoke pass not to do anything (like !-enable-correct-eh-support
does). This way, if you turn on -enable-eh then you get some kind of
eh support on all targets (emulated using sj/lj if the target does not
support dwarf eh). The testsuite can thus just use -enable-eh. If you
don't want eh at all then don't pass -enable-eh. If you only want eh
on targets that support dwarf eh then you can pass -enable-eh -disable-eh-emulation.
Ciao,
Duncan.
Hi Dale,
If these were visible to end users I would not like exposing sjlj, an
implementation detail; however my understanding is that they aren't. On the basis that they're intended for use by llvm geeks, I think
either of these is an improvement, except in the second case I think
the default should be target-dependent. Comments?
How about having -enable-eh turn on dwarf eh on all targets (including
those that don't support it, in which case intrinsics get lowered to
nothing much IIRC), and also have it cause a LowerInvoke pass to be run
on targets that do not support dwarf eh.
This also makes sense to me. The disadvantage being that you can only access one EH model for each target this way. With -eh-model={foo} you can pick.
support dwarf eh). The testsuite can thus just use -enable-eh. If you
don't want eh at all then don't pass -enable-eh. If you only want eh
on targets that support dwarf eh then you can pass -enable-eh -disable-eh-emulation.
Ok, so it sounds like you want a way to "enable the default eh model", and I want the ability to pick for "power users". How about something like:
<nothing> -> eh disabled (aka -fno-exceptions in gcc)
-enable-eh -> target default
-enable-eh=default -> target default
-enable-eh=sjlj
-enable-eh=dwarf
?
-Chris
I'm strongly of the opinion that you shouldn't have to say anything to get EH on targets where it works.
-fexceptions is set up like that.
I'm not sure I get what you mean. gcc defaults to no EH data, you need -fexceptions to turn it on. g++ defaults it to on, because it knows the front-end. You think we should have llc default to EH on when the target supports it? Don't all targets support sjlj?
-Chris
I'm strongly of the opinion that you shouldn't have to say anything to
get EH on targets where it works.
-fexceptions is set up like that.I'm not sure I get what you mean. gcc defaults to no EH data, you need
-fexceptions to turn it on. g++ defaults it to on, because it knows the
front-end. You think we should have llc default to EH on when the target
supports it?
The target and the source language, yes. I agree it should be off by default
for C, so I guess what I want is to encode the -fexceptions value in the IR.
People with C++ programs shouldn't need a BE flag to make a fundamental
language feature work.
Don't all targets support sjlj?
Apparently not, since there were a lot of new passes when I changed
-enable-eh-correct to -enable-eh. I haven't looked into the sjlj implementation
at all though, so I can't say why.
front-end. You think we should have llc default to EH on when the target supports it?
The target and the source language, yes. I agree it should be off by default for C, so I guess what I want is to encode the -fexceptions value in the IR. People with C++ programs shouldn't need a BE flag to make a fundamental language feature work.
That is an interesting point. Maybe there should be a function attr that says the function needs unwind info? Duncan, what do you think?
Don't all targets support sjlj?
Apparently not, since there were a lot of new passes when I changed -enable-eh-correct to -enable-eh. I haven't looked into the sjlj implementation at all though, so I can't say why.
Ok. I wouldn't be suprised if it was bitrotted or something, it gets little love.
-Chris
Hi,
> I'm not sure I get what you mean. gcc defaults to no EH data, you
> need
> -fexceptions to turn it on. g++ defaults it to on, because it knows
> the
> front-end. You think we should have llc default to EH on when the
> target
> supports it?The target and the source language, yes. I agree it should be off by
default
for C, so I guess what I want is to encode the -fexceptions value in
the IR.
I don't see the point. If you don't have -fexceptions then you don't
get any exception handling constructs generated in the IR in the place.
The costs of turning on -enable-eh for IR with no eh constructs are:
(1) frame info generated all over the place; (2) reduced branch folding
due to nounwind calls being bracketed by labels. However (1) could
easily be improved - currently we generate frame info always if -enable-eh
is turned on, even if there is no need for it. As for (2) I doubt it
costs much. In short turning on -enable-eh seems rather harmless and could
be made even more harmless.
People with C++ programs shouldn't need a BE flag to make a fundamental
language feature work.> Don't all targets support sjlj?
Apparently not, since there were a lot of new passes when I changed
-enable-eh-correct to -enable-eh. I haven't looked into the sjlj
implementation
at all though, so I can't say why.
Well it doesn't handle things like... testing which exception it was!
(eh.selector and all that) So it's not surprising some thing started
working.
Ciao,
Duncan.
Ok, so it sounds like you want a way to "enable the default eh model", and
I want the ability to pick for "power users". How about something like:<nothing> -> eh disabled (aka -fno-exceptions in gcc)
-enable-eh -> target default
-enable-eh=default -> target default
-enable-eh=sjlj
-enable-eh=dwarf?
Sounds good to me.
D.