<br><br><div class="gmail_quote">On Wed, Aug 22, 2012 at 10:23 PM, Xi Wang <span dir="ltr"><<a href="mailto:xi.wang@gmail.com" target="_blank">xi.wang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
User-supplied range information would be useful for both static analyzers and optimizers.  For static analyzers, the information can be used to reduce false positives if the developer knows the physical limit of some variables.  For the backend, the information can provide more precise value ranges for optimizations.<br>

<br>
How about a new range attribute that allows developers to annotate range information?<br>
<br>
Here's a prototype implementation that adds the range attribute to clang and emits range metadata.<br>
<br>
  <a href="https://github.com/xiw/clang/compare/range" target="_blank">https://github.com/xiw/clang/compare/range</a><br>
<br>
Here's an example.<br>
<br>
  struct A {<br>
      int x;<br>
      int y __attribute__((range(100, 200)));<br>
  };<br>
<br>
  int z __attribute__((range(250, 500)));<br>
<br>
  int foo(struct A *a)<br>
  {<br>
      return a->y + z;<br>
  }<br>
<br>
// CHECK: load i32* %y, align 4, !range !0<br>
// CHECK: load i32* @z, align 4, !range !1<br>
<br>
// CHECK: !0 = metadata !{i32 100, i32 201}<br>
// CHECK: !1 = metadata !{i32 250, i32 501}<br>
<br>
One bummer is that !range can only be attached to load instructions, and thus the patch doesn't support range attributes on function return values (or parameters).  Maybe we can generate some module metadata instead?<br>

<br>
- xi<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br>Richard Smith spoke about detecting integer overflow/underflow in his own RFC for catching as much undefined behavior as possible; I believe this would interact with this proposal since getting out of the range should probably be seen as overlfowing/underflowing.<br>
<br>I added him so he does not miss this.<br><br>-- Matthieu.<br>