NaCl's x86 DataLayout should specify an alignment for f80

[jfb]

Summary

This is a follow-up to D2436.

NaCl on x86 doesn't support x87, but it sometimes happens that an f80 value gets temporarily created nonetheless, causing DataLayout::getAlignmentInfo to assert out when selecting fp_extend. This problem shows up when compiling:

pnacl-llc -mtriple=i686-none-nacl-gnu -filetype=obj -O3 -mcpu=pentium4m compiler-rt/lib/floatdidf.c

It's not clear why fp_entend gets generated and then removed, it looks like ISel starts with:

; Function Attrs: nounwind readnone
define double @__floatdidf(i64 %a) #0 {
entry:
  %shr3 = lshr i64 %a, 32
  %conv = trunc i64 %shr3 to i32
  %conv1 = sitofp i32 %conv to double
  %mul = fmul double %conv1, 0x41F0000000000000
  %and = and i64 %a, 4294967295
  %or = or i64 %and, 4841369599423283200
  %sub = fadd double %mul, 0xC330000000000000
  %0 = bitcast i64 %or to double
  %add = fadd double %0, %sub
  ret double %add
}

And generates:

BB#0: derived from LLVM BB %entry
%vreg0<def> = MOV32rm <fi#-1>, 1, %noreg, 0, %noreg; mem:LD4[FixedStack-1](align=16) GR32:%vreg0
%vreg1<def> = CVTSI2SDrm <fi#-1>, 1, %noreg, 4, %noreg; mem:LD4[FixedStack-1+4] FR64:%vreg1
%vreg2<def,tied1> = MULSDrm %vreg1<tied0>, %noreg, 1, %noreg, <cp#0>, %noreg; mem:LD8[ConstantPool] FR64:%vreg2,%vreg1
MOV32mr <fi#0>, 1, %noreg, 0, %noreg, %vreg0<kill>; mem:ST4[FixedStack0](align=8) GR32:%vreg0
MOV32mi <fi#0>, 1, %noreg, 4, %noreg, 1127219200; mem:ST4[FixedStack0+4]
%vreg3<def,tied1> = ADDSDrm %vreg2<tied0>, %noreg, 1, %noreg, <cp#1>, %noreg; mem:LD8[ConstantPool] FR64:%vreg3,%vreg2
%vreg4<def,tied1> = ADDSDrm %vreg3<tied0>, <fi#0>, 1, %noreg, 0, %noreg; mem:LD8[FixedStack0] FR64:%vreg4,%vreg3
MOVSDmr <fi#1>, 1, %noreg, 0, %noreg, %vreg4<kill>; mem:ST8[FixedStack1] FR64:%vreg4
%vreg5<def> = LD_Fp64m80 <fi#1>, 1, %noreg, 0, %noreg, %FPSW<imp-def,dead>; mem:LD8[FixedStack1](align=4) RFP80:%vreg5
RETL %vreg5<kill>; RFP80:%vreg5

The final code gets rid of LD_Fp64m80, so this may be exposing another bug, or may simply be some form of canonicalization. Clarifications welcome here.

[echristo]

I think this is exposing a different bug. You may need to make sure that all of the fp80 bits are marked as not legal for NaCl.

lib/Target/X86/X86Subtarget.cpp

static std::string computeDataLayout(const Triple &TT) {
 
   // Some ABIs align 64 bit integers and doubles to 64 bits, others to 32.
   if (TT.isArch64Bit() || TT.isOSWindows() || TT.isOSNaCl())
     Ret += "-i64:64";
   else
     Ret += "-f64:32:64";
 
   // Some ABIs align long double to 128 bits, others to 32.
-  if (TT.isOSNaCl())
-    ; // No f80
-  else if (TT.isArch64Bit() || TT.isOSDarwin())
+  if (TT.isArch64Bit() || TT.isOSDarwin())
     Ret += "-f80:128";
   else
     Ret += "-f80:32";
 
   // The registers can hold 8, 16, 32 or, in x86-64, 64 bits.
   if (TT.isArch64Bit())
     Ret += "-n8:16:32:64";
   else
X86Subtarget::X86Subtarget(const std::string &TT, const std::string &CPU,
   } else if (isTargetELF()) {
     setPICStyle(PICStyles::GOT);
   }
 }
 
 bool X86Subtarget::enableEarlyIfConversion() const {
   return hasCMov() && X86EarlyIfConv;
 }
-