<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 29, 2021, at 06:43, Clement Courbet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 28, 2021 at 5:44 PM Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">
On 3/28/21 3:49 AM, James Courtier-Dutton wrote:<br class="">
> Actual use cases can get much more complicated with for example,<br class="">
> non-contiguous ranges. e.g. 0,1,4,5 ok, but 2,3,6,7 not ok.<br class=""></blockquote><div class=""><br class=""></div><div class="">This can actually be represented by !range metadata, but only for constant values.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That said, in operand bundles we can generally allow non-constant<br class="">
values, e.g., `["range"(%p, i32 0, i32 %N)]`<br class=""></blockquote><div class=""><br class=""></div><div class="">That's a good point and it essentially disqualifies !range metadata if we want to one day be able to deal with values..</div><div class=""> </div><div class=""><div class=""></div><div class="">> This means we have to handle multiple variants across the codebase, which can lead to situations where only one or the other is handled<br class=""></div><div class=""><br class=""></div><div class="">I don't think this is really an issue, because whatever the choice of representation is, all these variants should be using `ValueTracking` to abstract the representation anyway.</div></div></div></div></div></blockquote><br class=""></div><div>There are some passes for which ValueTracking in the current form is not suitable, e.g. because they propagate information forward, rather than querying backwards on-demand as in ValueTracking. </div><div><br class=""></div><div>I don’t doubt that we can come up with a reasonable abstraction to make dealing with this easier, especially for the constant/plain value ranges.</div><div><br class=""></div><div><br class=""></div><div>Anyways, it feels like the discussion got a bit sidetracked (sorry!) and I think we should probably focus on the main proposal at hand. I’d recommend to go with whatever is supported well on current main for this proposal and discuss the assume bundles separately.</div><div><br class=""></div><div>Cheers,</div><div>Florian</div></div></body></html>