On Wed, Jul 5, 2017 at 3:59 PM, Hal Finkel via llvm-dev < 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 >>> >>> >>> -- >>> >>> Alexandre Isoard >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> 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 > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/1f643272/attachment.html>
Ah, ok. I read it wrong. In *neither* case it is UB. Hum, can an implementation define it as UB? :-) On Wed, Jul 5, 2017 at 9:09 PM, Alexandre Isoard <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> 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 >>>> >>>> >>>> -- >>>> >>>> Alexandre Isoard >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> 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 >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > > -- > *Alexandre Isoard* >-- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170705/7806032c/attachment.html>
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>