llvm dev - Mar 2009 - [LLVMdev] Multiple return values (floating-point exception flags)

Does anyone have suggestions for either extending operators or
adding intrinsics that support multiple return values?  Or is
packaging everything into a derived types the only way?

I have an idea for supporting floating-point exception flags and
modes in a flexible way by making the data dependencies explicit,
but I've become quite lost poking around.  I suspect this will
end up involving some combinations of intrinsics and, alas, rely
on derived type optimizations combined with SelectionDAG nodes
for sensible performance.  But simply returning the flags seems
nicer, e.g.
  <result>, <flags> = floatadd <result-format> <op1>
<op2> <fpu-mode>
If the flags are to be ignored, it should be relatively easy to
dispose of them with multiple return values.

(Part of this (very long-term) work would be to decide if it's
better to pass flags as input and return the OR (as currently is
done in hardware) or to keep the OR separate.)

Right now, I'm somewhat terrified of supporting LLVM users.  I
don't see how it catches any of the implicit data dependencies
that occur in the floating-point environment...  Other compilers
finally are working with the FPU environment, but LLVM's link-time
optimizations without any of the barriers seems capable of
wreaking severe havoc.

Jason

On Wed, Mar 18, 2009 at 2:22 PM, Jason Riedy <jason at acm.org>
wrote:
> Does anyone have suggestions for either extending operators or
> adding intrinsics that support multiple return values?
Intrinsics already support multiple return values. See
int_sadd_with_overflow and friends.
>  Or is
> packaging everything into a derived types the only way?
>
There's already support for multiple return values in LLVM. It's been
there since LLVM 2.3. :-)
> I have an idea for supporting floating-point exception flags and
> modes in a flexible way by making the data dependencies explicit,
> but I've become quite lost poking around.  I suspect this will
> end up involving some combinations of intrinsics and, alas, rely
> on derived type optimizations combined with SelectionDAG nodes
> for sensible performance.  But simply returning the flags seems
> nicer, e.g.
>  <result>, <flags> = floatadd <result-format> <op1>
<op2> <fpu-mode>
> If the flags are to be ignored, it should be relatively easy to
> dispose of them with multiple return values.
>
You should check out the work done for "integer arithmetic with
overflow". It's done via intrinsics.

-bw
> (Part of this (very long-term) work would be to decide if it's
> better to pass flags as input and return the OR (as currently is
> done in hardware) or to keep the OR separate.)
>
> Right now, I'm somewhat terrified of supporting LLVM users.  I
> don't see how it catches any of the implicit data dependencies
> that occur in the floating-point environment...  Other compilers
> finally are working with the FPU environment, but LLVM's link-time
> optimizations without any of the barriers seems capable of
> wreaking severe havoc.
>
> Jason
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

And Bill Wendling writes:
> > Or is packaging everything into a derived types the only way?
>
> There's already support for multiple return values in LLVM. It's
been
> there since LLVM 2.3. :-)
Thanks for the reference!  I meant multiple return values in the
manner of Lua, Octave, etc.  The first value is necessary, and
later values can be ignored.  But I can see reasons for keeping all
of them and forcing later passes to cope.
>From the documentation of llvm.sadd.with.overflow:
  "They return a structure [...]"
That specifically was what I was hoping to avoid, but existing
optimizations around the integer overflow support should help me.
Thanks!

Jason