On Wed, 09 Nov 2011 09:27:30 -0800, Devang Patel wrote:> On Nov 9, 2011, at 12:52 AM, cafxx wrote: > >> I was wondering, is there any way to express in the IR that an >> instruction/instruction sequence/basic >> block/region/function/module/whatever is an alternate version of >> another? > > There is not a way to represent --- instruction I1 is an alternative > for instruction I2 --- in LLVM IR.Could there be any interest in this functionality? Do you think bending the meaning of existing constructs like select i1 undef, <ty> <val0>, <ty> <val1> (for instructions) or switch i1 undef, label <bb0>, i1 1, label <bb1> (for basic blocks) could be feasible/acceptable?
On Thu, 10 Nov 2011 10:17:09 +0100, cafxx wrote:> On Wed, 09 Nov 2011 09:27:30 -0800, Devang Patel wrote: >> On Nov 9, 2011, at 12:52 AM, cafxx wrote: >> >>> I was wondering, is there any way to express in the IR that an >>> instruction/instruction sequence/basic >>> block/region/function/module/whatever is an alternate version of >>> another? >> >> There is not a way to represent --- instruction I1 is an alternative >> for instruction I2 --- in LLVM IR. > > Could there be any interest in this functionality? Do you think > bending > the meaning of existing constructs like > select i1 undef, <ty> <val0>, <ty> <val1> > (for instructions) or > switch i1 undef, label <bb0>, i1 1, label <bb1> > (for basic blocks) could be feasible/acceptable?I forgot, the above instructions should be (optionally) marked with metadata so that alternates-aware passes can recognize them, e.g. select i1 undef, <ty> <val0>, <ty> <val1>, !alternates switch i1 undef, label <bb0>, i1 1, label <bb1>, !alternates
Hi Carlo, the general policy is to canonicalize IR to some particular choice. For example, if I1, I2, etc are all equivalent to each other, then usually one of them will have been chosen as the canonical form (say I1) and all the others will be turned into I1. If this is not the best choice for some target, then the code generators for that target need to transform it into something better for the target, but this is not at the IR level. Ciao, Duncan. On 10/11/11 10:17, cafxx wrote:> On Wed, 09 Nov 2011 09:27:30 -0800, Devang Patel wrote: >> On Nov 9, 2011, at 12:52 AM, cafxx wrote: >> >>> I was wondering, is there any way to express in the IR that an >>> instruction/instruction sequence/basic >>> block/region/function/module/whatever is an alternate version of >>> another? >> >> There is not a way to represent --- instruction I1 is an alternative >> for instruction I2 --- in LLVM IR. > > Could there be any interest in this functionality? Do you think bending > the meaning of existing constructs like > select i1 undef,<ty> <val0>,<ty> <val1> > (for instructions) or > switch i1 undef, label<bb0>, i1 1, label<bb1> > (for basic blocks) could be feasible/acceptable? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, 10 Nov 2011 10:46:27 +0100, Duncan Sands wrote:> Hi Carlo, the general policy is to canonicalize IR to some particular > choice. For example, if I1, I2, etc are all equivalent to each > other, > then usually one of them will have been chosen as the canonical form > (say I1) and all the others will be turned into I1. If this is not > the best choice for some target, then the code generators for that > target need to transform it into something better for the target, but > this is not at the IR level.This might work for single instructions or simple instruction sequences but doesn't apply to, let's say, regions. As an example, take a loop that could be rewritten (unrolled, tiled, etc.) so that different versions of the same loop have wildly different memory access patterns. In this case, in order to choose the "best" version, the IR-level transform would have to know the details of the cache/memory subsytems of the current arch.