This error suggests things are working on the generic LLVM side (as
I'd expect). It's what I'd expect to see for your code snippet if
there wasn't a target-specific pattern that could handle the addition
properly and select it to a valid instruction. What patterns do you
have for f16 addition so far?
If there's really nothing obviously wrong with them, the next step is
probably to delve into what the DAG matcher is doing behind the
scenes. If you give llc the option "-debug" it should tell you what
patterns it's tried to match against the fadd and where they failed.
If you cross-reference this with the table in
build/lib/Target/XXX/XXXGenDAGISel.inc you should be able to work out
where things are going wrong. (There are comments giving what each
original pattern was *below* the check that'll fail in each case).
As we are working on half float fp16 support in LLVM are there any plans to
support it on the main trunk ?
As I sort of implied, it's mostly down to the targets implementing
support now. The generic LLVM code doesn't need to do much with it. I
suppose there could be parts of the DAG combiner that assume
float/double or calls out to runtime library support functions that
aren't implemented, but that's not what you're hitting here. In fact
I'd expect most of the generic code to simply not care whether the
float it was considering is 16/32/64-bits wide and Just Work for
16-bit ones.
after a long time i managed to make a progress with this problem. i can store
and load fp16 as i16 in to some registers and do an add instruction. the
problem now is that this messes up the real i16 (short, unsigned short).
so i can have a half floating point add two half point variables and seems
to work fine.
This does not look right. Note that you're matching f16_to_f32
intrinsics and friends. They are used for storage-only half FP stuff
and you're trying to match them instead of native fp16.
So, in short - you need to generate IR with proper fp16 arithmetics,
not via storage-only wrappers.
i understand that is not right but this was the only way not to use the fadd
for f32 "add.s" and use the "add.h" what ever i tried llvm moved everything
to the float registers and did add.s and not the half add.h
is there any trick to do that? i tried a lot but with no luck
i understand that is not right but this was the only way not to use the fadd
for f32 "add.s" and use the "add.h" what ever i tried llvm moved everything
to the float registers and did add.s and not the half add.h
It seems you do not understand the issue.
Half floating poing operations can be done in two ways:
1. Storage-only (fp16 is used to store value, all the operations are
performed on floats). For such f32 <-> f16 conversion the special
intrinsic is used (which is lowered to native instruction on ARM NEON
for example)
2. Native fp16.
Note that for both mode *frontend* is involved, because in case of 1.
it should generate appropriate conversion when necessary.
It seems that you have IR from 1. case, but you really want to do
stuff in mode 2. So, generate proper IR (with native fp16 operations,
not storage only stuff) and almost all your problems will go away.
you had right
i used opencl patch for clang to generate IR with half and after that
declared fp16 legal instructions and some defs and it worked.
the with a load half fp with immediate instruction.
p.s
then i did something i can not remember and it stopped :S
