Question: How hard should tblgen try to fit constants into a particular
My case is an xor with i8 immediate where I'm using 0xff in as the
immediate value. 0xff should fit into i8 if treated as unsigned, but
CodeGenDAGPatterns.cpp assumes that any and all integers less than
32-bits are signed.
Should tblgen try to see if the sign-extended version of the constant
could fit into the type, and failing that, try the unsigned version:
Allow me to rephrase my question: How much agony and gnashing of teeth will I cause if I commit this patch to tblgen (fully tested and changes to DAGISelEmitter.cpp also committed)?
Scott Michel wrote:
Allow me to rephrase my question: How much agony and gnashing of
teeth will I cause if I commit this patch to tblgen (fully tested and
changes to DAGISelEmitter.cpp also committed)?
I tested the aforementioned patch in the test subdirectory and the tests
The basic implication from this patch is that all constants emitted by
tblgen will be uint64_t hex constants and tblgen won't complain when a
sign-extended value won't fit i16 or i8 or i(i<32-bit) type even though
it would if it were treated as unsigned.
(who's not going to beg forgiveness if the patch isn't Lattnerized(tm))
My feeling is tblgen shouldn't make assumptions about whether the backend will treat the value as signed or unsigned (after all MVT::ValueType does not convey sign information). Perhaps it's cleaner to just check if it fits as unsigned? Chris?
I don't see why there is an issue. Can't you just write i8 -1 ?