[LLVMdev] Does nounwind have semantics?

[Andrew Trick]

On Jul 22, 2013, at 1:37 AM, Duncan Sands <baldrick at free.fr> wrote:

>> Good explanation. Your definition of nounwind is completely logical. I would
>> prefer not to rely on it though because
>> - Realistically, the semantics won’t be well tested.
> 
> this is true.  Those who need this will have to do careful testing and bug
> fixing themselves.  But to my mind this is not a reason to abandon these
> semantics.  A good reason to abandon these semantics is if they created trouble
> for a large number of users, e.g. clang, for example by making it hard to do
> important optimizations.  Do they?  Are these semantics actively harmful?
> If not I'd prefer to keep them since they are fairly clean.

I was justifying my decision not to pursue fixing bugs related to this because of the futility. But you’re right, they can probably be fixed without anyone complaining about performance.

>> - It doesn’t seem terribly important to treat nonlocal gotos as readonly (though
>> maybe it is to you :)
> 
> It's not a problem for me, I just like to keep orthogonal things orthogonal.
> Maybe that's a mistake and we should rename readonly to "nothing funky happens".
> 
>> - When it is important to optimize memory access around nonlocal gotos, I prefer
>> to expose control flow to the optimizer explicitly.
>> e.g. why not just use invokes for all your may-throw calls, then you’re free to
>> mark them readonly?
> 
> Let's say that we are in function foo.  We call bar.  We were called by qaz.
> I'm not talking about non-local gotos that jump from bar to somewhere in us
> (foo).  These indeed need to be modelled with invoke.  I'm talking about those
> that jump from bar to somewhere in qaz.  That means that the place in qaz that
> called us (foo) will need to use an invoke.  But from the point of view of foo,
> the call to bar never returns to foo, it just instantly leaps across foo all the
> way up to qaz and execution continues there.  So foo doesn't need to do anything
> much, all the heavy lifting is in bar and in qaz.  All foo has to do is keep in
> mind that control may never get to the next instruction after the call to bar.

I’m saying that in some hypothetical language where we need to optimize across readonly exception throwing calls, that both calls to foo and qaz could be invokes (assuming the optimizer doesn’t downgrade the invoke-foo). The concept of a may-throw call with implicit control flow is a shortcut for implementing C++ exceptions that makes the IR a tad prettier. The shortcut happens to work most of the time because the calls always write memory. My only point here is that runtimes can still do exceptions however they like and the front end doesn't need your semantics to do it.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130722/2d5d585a/attachment.html>