Disabling emitting x86_fp80/ppc_fp128 IR

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Disabling emitting x86_fp80/ppc_fp128 IR

Sumner, Brian via cfe-dev
Hi all,

I'm sure this has been answered somewhere but I can't seem to find it.  I've got an application that uses the long double type in a couple of places.  Is there a way to prevent clang from emitting architecture-specific floating point types, i.e., "x86_fp80" & "ppc_fp128", and instead force clang to only emit "fp128" types?  It seems like LLVM's backends can easily handle this by emitting soft floating point routines (defined in the "compiler-rt" project) for dealing with these types.  However, I don't want to force soft floating point routines for other types, i.e., "half", "float" and "double".

Thanks!

--
Rob Lyerly
Graduate Research Assistant, Systems Software Research Group

  

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling emitting x86_fp80/ppc_fp128 IR

Sumner, Brian via cfe-dev
Hi all,

According to this thread (http://www.openwall.com/lists/musl/2016/03/11/18), clang does not support emitting architecture-independent "fp128" types for PowerPC & x86-64, but instead will only emit their architecture-specific long double types.  One alternative the thread suggests is to to force GCC to demote long double types to be equivalent to normal 64-bit doubles.  Is there a way to enforce this behavior using clang, i.e., force clang to emit IR "double" types for values declared as "long double" in the source code?

On Thu, Aug 3, 2017 at 11:09 AM, Rob Lyerly <[hidden email]> wrote:
Hi all,

I'm sure this has been answered somewhere but I can't seem to find it.  I've got an application that uses the long double type in a couple of places.  Is there a way to prevent clang from emitting architecture-specific floating point types, i.e., "x86_fp80" & "ppc_fp128", and instead force clang to only emit "fp128" types?  It seems like LLVM's backends can easily handle this by emitting soft floating point routines (defined in the "compiler-rt" project) for dealing with these types.  However, I don't want to force soft floating point routines for other types, i.e., "half", "float" and "double".

Thanks!

--
Rob Lyerly
Graduate Research Assistant, Systems Software Research Group

  



--
Rob Lyerly
Graduate Research Assistant, Systems Software Research Group

 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disabling emitting x86_fp80/ppc_fp128 IR

Sumner, Brian via cfe-dev
In reply to this post by Sumner, Brian via cfe-dev
On 8/3/2017 8:09 AM, Rob Lyerly via cfe-dev wrote:

> Hi all,
>
> I'm sure this has been answered somewhere but I can't seem to find
> it.  I've got an application that uses the long double type in a
> couple of places.  Is there a way to prevent clang from emitting
> architecture-specific floating point types, i.e., "x86_fp80" &
> "ppc_fp128", and instead force clang to only emit "fp128" types?  It
> seems like LLVM's backends can easily handle this by emitting soft
> floating point routines (defined in the "compiler-rt" project) for
> dealing with these types. However, I don't want to force soft floating
> point routines for other types, i.e., "half", "float" and "double".

You can write "__float128" to get an fp128 on any target which supports it.

There is no option to modify the type of "long double"; ABI-changing
options are generally dangerous (code compiled with the flag is
incompatible with code compiled without it).

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...