[LLVMdev] Multiple return values (floating-point exception flags)

Bill Wendling isanbard at gmail.com
Wed Mar 18 14:55:58 PDT 2009


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
>




More information about the llvm-dev mailing list