[llvm-dev] always allow canonicalizing to 8- and 16-bit ops?

[Alex Bradbury via llvm-dev]

On 17 January 2018 at 22:50, Sanjay Patel via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Example:
> define i8 @narrow_add(i8 %x, i8 %y) {
>   %x32 = zext i8 %x to i32
>   %y32 = zext i8 %y to i32
>   %add = add nsw i32 %x32, %y32
>   %tr = trunc i32 %add to i8
>   ret i8 %tr
> }
>
> With no data-layout or with an x86 target where 8-bit integer is in the
> data-layout, we reduce to:
>
> $ ./opt -instcombine narrowadd.ll -S
> define i8 @narrow_add(i8 %x, i8 %y) {
>   %add = add i8 %x, %y
>   ret i8 %add
> }
>
> But on a target that has 32-bit registers without explicit subregister ops,
> we don't do that transform because we avoid changing operations from a legal
> (as specified in the data-layout) width to an illegal width - see
> InstCombiner::shouldChangeType().
>
> Should we make an exception to allow narrowing for the common cases of i8
> and i16?

The current implementation of 64-bit code generation for RISC-V has
i64 as the only legal type - with Krzysztof's variable-size register
class support, simply switching GPRs to i64 was the path of least
resistance for getting working codegen. In that case, it would be
interesting to explore allowing narrowing for i32 as well.

I should note: RV64I codegen isn't yet upstreamed primarily as I want
to do more investigation and thinking about the pros/cons of this
approach and discuss on llvm-dev. I don't want to derail this thread
with that discussion.

Best,

Alex