[llvm-dev] trunc nsw/nuw?

Hal Finkel via llvm-dev
Fri, 07 Jul 2017 00:38:38 -0000

On 07/06/2017 09:24 AM, Alexandre Isoard wrote:
> Hi Hal,
>
> I just want to check I understand correctly the subtlety, in C++ an
> overflowing signed addition is an undefined behavior (so Clang adds
> the nsw keyword to the sign add), while a signed cast that overflow is
> "only" implementation defined (so Clang cant risk to produce
poison on
> trunc). Is that right?

Correct.

>
> If trunc produced undef instead of poison, clang could use it, but
> then it is less useful and/or unwanted?

If the behavior was undefined, then we could have a flag that carried
the possibility of producing poison. But the standard requires us to
define the behavior, so we need to give the construct some well-defined
meaning (which might be platform dependent). It is "just" a matter of
the choices made by the standards committee(s).

  -Hal

>
> On Wed, Jul 5, 2017 at 10:30 PM, Hal Finkel <hfinkel at anl.gov
> <mailto:hfinkel at anl.gov>> wrote:
>
>
>     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
>
>
>
>
> --
> *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/20170706/dd139c4d/attachment.html>