[PATCH] Encode native floating point types in data layout string.

[Cameron Esfahani]

Comments inline

Cameron Esfahani
dirty at apple.com

"All that is necessary for the triumph of evil is that good men do nothing."

Edmund Burke



> On Dec 19, 2014, at 9:36 AM, Tim Northover <t.p.northover at gmail.com> wrote:
> 
> On 16 December 2014 at 16:16, Cameron Esfahani <dirty at apple.com> wrote:
>> My first attempt at using Phabricator didn't work so well.  Should I be adding llvm-commits as a reviewer or a subscriber?
> 
> I think subscriber usually sends messages to the list. Do you have a
> corresponding Clang patch for this? It sets datalayouts and needs to
> be kept in precise sync with the backends at the moment.
> 

I'll look at this.

>> Attached is patch proposal to encode native floating point types into the data layout string.
> 
> We'll want to update the LangRef documentation for this.
> 
>> ARM: 16-bit (if supported), single, and double (if supported) precision float.
> 
> I wouldn't have said 16-bit was native. It'll get promoted to float
> one way or the other for any actual operations. You just might be
> lucky enough that there are instructions to do that conversion for
> you.
> 

I've been using Wikipedia for most of the processors that I don't know well.  In this case, I looked more carefully and went to ARM directly.  According to: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205j/CIHGAECI.html half-precision floating point is an extension to VFPv3.  Does hasFP16 not reflect whether this extension is present?

> +    else if (ST.useNEONForSinglePrecisionFP())
> +      Ret += "-nf32";
> 
> I also don't think this logic is right for ARM. You probably want
> ST.isFPOnlySP().
> 

Okay, then I'll probably have to change my routine hasFloatingPoint() to ignore the NEON case:

  bool hasFloatingPoint() const { return HasVFPv2 || HasVFPv3 || HasVFPv4 || HasFPARMv8 || HasNEON; }

becomes

  bool hasFloatingPoint() const { return HasVFPv2 || HasVFPv3 || HasVFPv4 || HasFPARMv8; }


> I'm not an expert in any other targets, but I'd be surprised if PPC
> supported fp128 efficiently. As far as I'm aware it has a pseudo-128
> format of its own, which relies on 64-bit operations. There may be
> other ABIs that use IEEE 128-bit, but probably not efficiently.
> Whether it's efficient or not is debatable. You'll want to get PPC
> people to comment on this (and their own targets) though.
> 

FP128 is only in the PPC64 case.  From what I could tell, it looks like it was natively supported.  But, yes, I would hope that each of the target owners/experts would chime in with anything I did wrong.