[llvm-dev] Handling native i16 types in clang and opt

[Nemanja Ivanovic via llvm-dev]

Just a shot in the dark here...
could this possibly be that Clang (or whatever is adding those trunc/ext's
into the IR) is considering your calling conventions in
<TargetName>CallingConv.td?

We certainly get the same behaviour on PPC but I wonder if that's due to
lines like this in PPCCallingConv.td:
`CCIfType<[i8],  CCPromoteToType<i64>>`

I don't know enough about this code to really know whether the above has
any relation to reality, but it seems related.

On Mon, May 22, 2017 at 1:27 PM, Friedman, Eli via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 5/21/2017 1:22 AM, Alex Susu via llvm-dev wrote:
>
>>   Hello.
>>     My target architecture supports natively 16 bit integers (i16).
>>
>>     Whenever I write in C programs using only short types, clang compiles
>> the program to LLVM and converts the i16 data to i32 to perform arithmetic
>> operations and then truncates the results to i16. Then, the
>> InstructionCombining (INSTCOMBINE or IC) pass removes these conversions
>> back and forth from i16, except for the (s)div LLVM IR operation.
>>
>
> sdiv in particular is special: it has undefined behavior on overflow.
> "sdiv i32 -32768, -1" produces "i32 32768", but "sdiv i16 -32768, -1" is
> undefined.
>
> -Eli
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170529/4fd4e157/attachment.html>