[LLVMdev] nsw/nuw for trunc

[John McCall]

On Aug 11, 2011, at 10:58 AM, Florian Merz wrote:

> 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?

I can't imagine this going into the core IR.  You should either use
metadata or explicit control flow in the frontend.

> 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.

nsw on shl satisfies the two crucial properties of (1) actually providing
some generic value, instead of just being a way to communicate to
your specific out-of-tree analysis, and (2) actually encoding the semantics
of a real operation, to wit, the fact that it's undefined behavior if << on C's
signed integer types causes overflow.

>> 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.

Clang is actually somewhat laxer about taking extensions than LLVM is
about modifying its core IR.  That said, no, you would need to maintain
this out of tree.

John.