[PATCH] NaCl's x86 DataLayout should specify an alignment for f80

[JF Bastien]

Hi dschuff, rafael,

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.

http://reviews.llvm.org/D5807

Files:
  lib/Target/X86/X86Subtarget.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D5807.14965.patch
Type: text/x-patch
Size: 593 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141015/a8ef4177/attachment.bin>