[llvm-dev] [RFC] Adding range metadata to array subscripts.

Florian Hahn via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 30 14:39:22 PDT 2021



> On Mar 29, 2021, at 06:43, Clement Courbet via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> 
> On Sun, Mar 28, 2021 at 5:44 PM Johannes Doerfert via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> On 3/28/21 3:49 AM, James Courtier-Dutton wrote:
> > Actual use cases can get much more complicated with for example,
> > non-contiguous ranges. e.g. 0,1,4,5 ok, but 2,3,6,7 not ok.
> 
> This can actually be represented by !range metadata, but only for constant values.
>  
> That said, in operand bundles we can generally allow non-constant
> values, e.g., `["range"(%p, i32 0, i32 %N)]`
> 
> That's a good point and it essentially disqualifies !range metadata if we want to one day be able to deal with values..
>  
> > This means we have to handle multiple variants across the codebase, which can lead to situations where only one or the other is handled
> 
> 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.

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. 

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.


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.

Cheers,
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210330/d4acd328/attachment.html>


More information about the llvm-dev mailing list