[PATCH] Add FPExt option to CCValAssign::LocInfo

[Lang Hames]

Hi All,

At the moment, when generating calling convention functions, Tablegen
will mistakenly specify integer promotions for floating point types.
E.g, writing:

CCIfType<[f32], CCPromoteToType<f64>>

will generate:

if (LocVT == MVT::f32) {
  LocVT = MVT::f64;
  if (ArgFlags.isSExt())
      LocInfo = CCValAssign::SExt;
  else if (ArgFlags.isZExt())
      LocInfo = CCValAssign::ZExt;
  else
      LocInfo = CCValAssign::AExt;
}

This logic always return CCValAssign::AExt for FP promotions, since
isSExt() and isZExt() both return false for FP types. The resulting
combination isn't sane though, since AExt is an integer extend.

Backends that use the CCPromoteToType for FP values have been forced
to hack around this (E.g. AArch64). I think the proper solution is to
introduce an 'FPExt' option to CCValAssign::LocInfo, and have tablegen
produce something like:

if (LocVT == MVT::f32) {
  LocVT = MVT::f64;
  LocInfo = CCValAssign::FPExt;
}

The attached patch does this. The AArch64 backend is updated to treat
FPExt as AExt, preserving the existing hack, but allowing it to be
removed in the future. Sparc and X86 are updated to assert that they
never see an FPExt (if they had previously encountered an AExt for an
FP type we would have seen them explode already). All other backends
already had assertions to catch unexpected loc info options.

Out-of-tree targets that are currently expecting an FP/AExt combo will
need to update their code accordingly, but the required changes will
be trivial.

Could someone who's more familiar with the calling convention lowering
logic take a look at this before I commit?

Cheers,
Lang.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AddFPExtLocInfo.patch
Type: application/octet-stream
Size: 5081 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140109/f1305f71/attachment.obj>