llvm dev - Jun 2017 - Question about legal integer type

Hi All,

  I'd like to ask a question to see if i8 is legal or illegal type on
our target. We only support load/store for i8.
As for other operations, we usually do the following,

    loadi8   32-bit reg A, address
    addi32  32-bit reg A, imm

In other words, we will load i8 into a 32-bit register, then apply
32-bit operation on it. In this case, is i8 a legal
or illegal type? Currently, we treats it as *illegal*, but I find some
optimizations will be skipped. For example,
in InstCombiner::visitTrunc [1], it calls shouldChangeType, which
checks both Src and Dest are legal type,
then do optimization if shouldChangeType returns true.

Thanks.

[1] http://llvm.org/doxygen/InstCombineCasts_8cpp_source.html#l00517

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj

On 26 June 2017 at 06:11, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> In other words, we will load i8 into a 32-bit register, then apply
> 32-bit operation on it. In this case, is i8 a legal
> or illegal type?
This is extremely typical and in all similar backends I know of i8 is
illegal despite that.
> Currently, we treats it as *illegal*, but I find some
> optimizations will be skipped. For example,
> in InstCombiner::visitTrunc [1], it calls shouldChangeType, which
> checks both Src and Dest are legal type,
> then do optimization if shouldChangeType returns true.
Typically truncs and extensions are handled (and become free) during
ISel. You end up with zextload, sextload and truncstore nodes which
just do the obvious thing.

I haven't thought about that particular InstCombine, but given that
most LLVM targets have this behaviour the chances are it actually
improves the code in your case too.

Cheers.

Tim.