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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
