[PATCH] Allow __fp16 as a function arg or return type for AArch64

[Tim Northover]

Hi Oliver,

I've done some more thinking about this, and posted an RFC to llvmdev and cfe-dev with the direction I'd like to pursue here longer term.

Regardless of the outcome of that more general proposal, I don't think the AArch64 backend is ready to cope with the code this patch produces yet. Allowing "half" as a function argument immediately introduces more possible operations to the IR we have to deal with: bitcast and load/store for one.

For example, all three of these functions exhibit poor behaviour at the moment:

    __fp16 varFloat;

    short foo(__fp16 in) {
      // __fp16 bitcast lowered to load/store
      return *(short *)∈
    }

    __fp16 bar(short in) {
      // __fp16 bitcast lowered to load/store
      return *(__fp16 *)∈
    }

    float baz() {
      // extload would be created in DAG and crash ISel. Crashes clang instead.
      return varFloat;
    }

The last one actually crashes in Clang itself, which is worrying, since I was expecting an LLVM backend crash and hadn't spotted anything obviously wrong with this patch. I've not investigated exactly what's wrong there though.

The bitcasts are particularly nasty because, as far as I can see, there *is* no generic way to express a "half <-> i16" bitcast when the latter type is illegal (as it is for us). The best I've come up with this afternoon is EXTRACT_SUBREG or SUBREG_TO_REG, but creating those during ISelLowering is really ugly; if you have any suggestions...

Cheers.

Tim.

http://reviews.llvm.org/D4456