Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] nsw/nuw for trunc"
2011 Aug 11
0
[LLVMdev] nsw/nuw for trunc
Hi Florian,
> we'd like to be able to check for loss of information in trunc operations in
> our LLVM-based bounded model checker [1]. For this it is important if the
> trunc was on a signed or unsigned integer, so we need nsw and nuw flags for
> this. Would you accept a patch that adds these flags to LLVM (and possibly
> clang)?
nsw/nuw don't mean signed/unsigned
2011 Aug 11
2
[LLVMdev] nsw/nuw for trunc
On Aug 11, 2011, at 11:03 AM, Chris Lattner wrote:
>
> On Aug 11, 2011, at 5:17 AM, Florian Merz wrote:
>
>> Hi everyone,
>>
>> we'd like to be able to check for loss of information in trunc operations in
>> our LLVM-based bounded model checker [1]. For this it is important if the
>> trunc was on a signed or unsigned integer, so we need nsw and nuw
2011 Aug 11
0
[LLVMdev] nsw/nuw for trunc
On Aug 11, 2011, at 5:17 AM, Florian Merz wrote:
> Hi everyone,
>
> we'd like to be able to check for loss of information in trunc operations in
> our LLVM-based bounded model checker [1]. For this it is important if the
> trunc was on a signed or unsigned integer, so we need nsw and nuw flags for
> this. Would you accept a patch that adds these flags to LLVM (and
2011 Aug 11
3
[LLVMdev] nsw/nuw for trunc
Hi Duncan,
Am Thursday, 11. August 2011, 15:56:22 schrieb Duncan Sands:
> Hi Florian,
>
> > we'd like to be able to check for loss of information in trunc operations
> > in our LLVM-based bounded model checker [1]. For this it is important if
> > the trunc was on a signed or unsigned integer, so we need nsw and nuw
> > flags for this. Would you accept a patch
2011 Sep 30
2
[LLVMdev] Definition of C/C++ integral conversion(was Re: nsw/nuw for trunc)
On 08/11/2011 02:56 PM, Duncan Sands wrote:
> Hi Florian,
>
>> we'd like to be able to check for loss of information in trunc operations in
>> our LLVM-based bounded model checker [1]. For this it is important if the
>> trunc was on a signed or unsigned integer, so we need nsw and nuw flags for
>> this. Would you accept a patch that adds these flags to LLVM (and
2011 Aug 11
1
[LLVMdev] nsw/nuw for trunc
On Aug 11, 2011, at19:34, John McCall wrote:
> On Aug 11, 2011, at 7:31 AM, Florian Merz wrote:
> > If we had nsw and nuw flags for truncations we'd know when to check for
> > this kind of overflow and when not. The compiler likely doesn't need
> > these flags and can still ignore them, for us they would be useful.
>
> Duncan's point is that this is totally
2011 Aug 11
0
[LLVMdev] nsw/nuw for trunc
On Aug 11, 2011, at 7:31 AM, Florian Merz wrote:
> If we had nsw and nuw flags for truncations we'd know when to check for this
> kind of overflow and when not. The compiler likely doesn't need these flags and
> can still ignore them, for us they would be useful.
Duncan's point is that this is totally different from the semantics of
nsw/nuw on other instructions, which
2017 Jul 03
2
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
2017 Jul 05
2
trunc nsw/nuw?
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?
2017 Jul 04
4
trunc nsw/nuw?
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
2011 Sep 30
0
[LLVMdev] Definition of C/C++ integral conversion(was Re: nsw/nuw for trunc)
On Fri, Sep 30, 2011 at 7:59 AM, Tobias Grosser <tobias at grosser.es> wrote:
> On 08/11/2011 02:56 PM, Duncan Sands wrote:
>> Hi Florian,
>>
>>> we'd like to be able to check for loss of information in trunc operations in
>>> our LLVM-based bounded model checker [1]. For this it is important if the
>>> trunc was on a signed or unsigned integer,
2017 Jul 05
3
trunc nsw/nuw?
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
2011 Aug 11
0
[LLVMdev] nsw/nuw for trunc
On Aug 11, 2011, at 11:32 AM, John McCall wrote:
>> On Aug 11, 2011, at 5:17 AM, Florian Merz wrote:
>>
>>> Hi everyone,
>>>
>>> we'd like to be able to check for loss of information in trunc operations in
>>> our LLVM-based bounded model checker [1]. For this it is important if the
>>> trunc was on a signed or unsigned integer, so
2017 Jul 06
2
trunc nsw/nuw?
According to 6.3.1.3/3 of the C standard (I didn't check C++):
"3 Otherwise, the new type is signed and the value cannot be represented
in it; either the result is implementation-defined or an
implementation-defined signal is raised."
I *think* that means that IF a signal is raised then the signal raised
could be one that you can't guarantee to be able to return from
2017 Jul 07
3
trunc nsw/nuw?
Hi,
Even if there are no ways in which a *frontend* can produce nsw
truncs, it may still be useful to have if optimization passes can
usefully attach nsw to truncates (after proving the truncates don't
"overflow"). For instance in
%a = ashr i64 %v, i32 33
%t = trunc %a to i32
the trunc can be marked nsw.
However, the burden of proof here is to show that we can do some
useful
2014 Sep 02
2
[LLVMdev] Preserving NSW/NUW bits
David/All,
Just a quick question about NSW/NUW bits, if you've got a second. I
noticed you've been doing a little work on this as of late.
I have a bit of code that looks like the following:
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
%2 = add i64 %indvars.iv.next, -1
%tmp = trunc i64 %2 to i32
%cmp = icmp slt i32 %tmp, %0
br i1 %cmp, label %for.body, label
2011 Sep 30
2
[LLVMdev] Definition of C/C++ integral conversion(was Re: nsw/nuw for trunc)
>> 3) If the destination type is signed, the value is unchanged if it
>> can be represented in the destination type (and bit-field
>> width); otherwise, the value is implementation-defined.
>> ----------------------------------------------------
>>
>> 4.7.3 suggest to me, that the standard does not define a result for
>> '(signed char)
2011 Oct 03
0
[LLVMdev] Definition of C/C++ integral conversion(was Re: nsw/nuw for trunc)
On 09/30/2011 04:46 PM, Duncan Sands wrote:
>>> 3) If the destination type is signed, the value is unchanged if it
>>> can be represented in the destination type (and bit-field
>>> width); otherwise, the value is implementation-defined.
>>> ----------------------------------------------------
>>>
>>> 4.7.3 suggest to me, that the standard does
2018 Aug 15
2
[SCEV] Why is backedge-taken count <nsw> instead of <nuw>?
Hello,
If I run clang on the following code:
void func(unsigned n) {
> for (unsigned long x = 1; x < n; ++x)
> dummy(x);
> }
I get the following llvm ir:
define void @func(i32 %n) {
> entry:
> %conv = zext i32 %n to i64
> %cmp5 = icmp ugt i32 %n, 1
> br i1 %cmp5, label %for.body, label %for.cond.cleanup
> for.cond.cleanup:
2018 Aug 15
2
[SCEV] Why is backedge-taken count <nsw> instead of <nuw>?
Is that why we do not deduce +<nsw> from "add nsw" either?
Is that an intrinsic limitation of creating a context-invariant expressions
from a Value* or is that a limitation of our implementation (our
unification not considering the nsw flags)?
On Wed, Aug 15, 2018 at 12:39 PM Friedman, Eli <efriedma at codeaurora.org>
wrote:
> On 8/15/2018 12:21 PM, Alexandre Isoard via