[llvm-dev] trunc nsw/nuw?
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 6 17:38:38 PDT 2017
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>
More information about the llvm-dev
mailing list