[llvm-dev] trunc nsw/nuw?

[Hal Finkel via llvm-dev]

On 07/05/2017 03:10 PM, Alexandre Isoard wrote:
> Ah, ok. I read it wrong. In *neither* case it is UB.
>
> Hum, can an implementation define it as UB? :-)

Nope :-)

The only case I've thought of where we could add these for C++ would be 
on conversions to (most) enums (because they used signed underlying 
types and the out-of-bounds mapping won't generally be one of the 
allowed values (or maybe we can define this to be the case?)).

  -Hal

>
> On Wed, Jul 5, 2017 at 9:09 PM, Alexandre Isoard 
> <alexandre.isoard at gmail.com <mailto:alexandre.isoard at gmail.com>> wrote:
>
>
>
>     On Wed, Jul 5, 2017 at 3:59 PM, Hal Finkel via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>
>         On 07/04/2017 01:41 AM, Dr.-Ing. Christoph Cullmann via
>         llvm-dev wrote:
>
>             Hi,
>
>                 Hi Alexandre,
>
>                 LLVM currently doesn't have trunc nsw/nuw, no.
>                 Which frontend would emit such instructions? Any
>                 application in mind?
>                 Just asking because if no frontend could emit those,
>                 then the motivation to
>                 add nsw/nuw support to trunc would be very low I guess.
>
>             I think the clang frontend could use that to allow better
>             static analysis of integer overflows
>             on the LLVM IR.
>
>             It might be interesting for static analysis tools that
>             want to know if you truncate something
>             that is too large for the target range but you need the
>             sign to determine, e.g. the C/C++ frontend
>             could use that flag for trunc of signed/unsigned integers,
>             then you could e.g. check if
>
>             (uint8_t)x
>
>             changes the values if x has stuff out of the 0..255 range.
>
>             e.g. x as int with -100 => trunc nuw to 8 => bad
>
>             (int8_t)x
>
>                => trunc nsw to 8 => ok
>
>
>         I'm not sure that a C/C++ frontend could add this flag. In
>         C++, the conversion for unsigned types is specified and for
>         signed types, it's implementation defined, but in neither case
>         is it UB.
>
>
>     Hmm, I don't get it.
>
>     Two questions:
>     - if the conversion for unsigned types is specified, how is it
>     undefined behavior?
>     - if the conversion for signed types is UB, then this is a direct
>     application of those flags, isn't it?
>
>          -Hal
>
>
>
>             Greetings
>             Christoph
>
>                 Thanks,
>                 Nuno
>
>                 -----Original Message-----
>                 From: Alexandre Isoard via llvm-dev
>                 Sent: Monday, July 3, 2017 8:38 PM
>                 To: llvm-dev
>                 Subject: [llvm-dev] trunc nsw/nuw?
>
>
>                 Hello,
>
>                  From [1], trunc does not seems to have a nsw/nuw
>                 attribute.
>                 Is it possible to have that? Or do we have that and it
>                 is not up-to-date?
>
>                 The definition would be:
>
>                 If the nuw keyword is present, the result value of the
>                 trunc is a poison
>                 value if the truncated high order bits are non-zero.
>                 If the nsw keyword is
>                 present, the result value of the trunc is a poison
>                 value if the truncated
>                 high order bits are not all equal to the non-truncated
>                 bit of the highest
>                 order.
>
>                 This allow to cancel out:
>                 - sext with trunc nsw
>                 - zext with trunc nuw
>
>                 And probably to commute with
>                 add/sub/mul/lshr/ashr/shl/urem/udiv/udiv (with
>                 the correct flags).
>
>                 [1]:
>                 http://llvm.org/docs/LangRef.html#trunc-to-instruction
>                 <http://llvm.org/docs/LangRef.html#trunc-to-instruction>
>
>
>                 --
>
>                 Alexandre Isoard
>
>                 _______________________________________________
>                 LLVM Developers mailing list
>                 llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>                 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>                 <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>         -- 
>         Hal Finkel
>         Lead, Compiler Technology and Programming Languages
>         Leadership Computing Facility
>         Argonne National Laboratory
>
>
>         _______________________________________________
>         LLVM Developers mailing list
>         llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>         http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>         <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
>
>     -- 
>     *Alexandre Isoard*
>
>
>
>
> -- 
> *Alexandre Isoard*

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/45ab2810/attachment.html>