[LLVMdev] nsw/nuw for trunc

Florian Merz florian.merz at kit.edu
Thu Aug 11 10:58:18 PDT 2011


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 different from the semantics of
> nsw/nuw on other instructions, which means it would be
> inappropriate to reuse nsw/nuw.  That's especially true because
> knowing that a trunc is nsw/nuw would be very useful to a lot of
> clients — the only problem is that nobody can think of any languages
> or situations where truncations actually have undefined behavior
> semantics.

Ok, then let's not call it nsw/nuw but something different, would that be 
acceptable? The information would be useful at least for software verification 
and static analysis, though admittedly not for the compiler itself. Our tool 
could spit out a warning, that the value has changed because of the 
truncation, which could be valuable information for the programmer. Also, 
adding such a flag would likely not hurt the compiler, would it?

Btw I think it's quite similar to the addition of nsw/nuw to shl, with the 
exception that that one actually allows some new optimizations, as afar as I 
know.

> You should probably just modify your frontend to emit explicit range
> checks in the cases you want.

That's certainly possible, but I guess it's even harder to push such a change 
into clang, than it is to push the additional of a flag for an instruction, 
which can be ignored by all passes, into llvm.

Regards,
 Florian




More information about the llvm-dev mailing list