[llvm-dev] [RFC] Interprocedural MIR-level outlining pass

[Daniel Berlin via llvm-dev]

(and in particular, the definition of equivalence used by code folding to
make the dags is STH like  "two VNDAG expressions are equivalent if their
operands come from VNDAG expressions with the same opcode")

Thus,

VN2 = VN0 + VN1
VN3 = VN1 + VN2

is considered equivalent to

VN2 = VN0 + VN5
VN3 = VN1 + VN2

Despite the fact that this is completely illegal for straight redundancy
elimination.


But again, as I said if y'all want to make a pass that basically generates
a new type of expression DAG, have fun :)

(I'm going to just leave this thread be now)



On Wed, Aug 31, 2016 at 4:17 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>> Yes, this was exactly my point. We want to recognize
>> structurally-equivalent sequences of instructions on inequivalent operands.
>>
>
> Yes, and my point is "none of the vn and vn-dag generating algorithms
> care".
>
> you can define equivalent to be "structural", you can define it to be
> "these two variables are equivalent if they both start with "a"", you can
> define it however you want.
> They will still give you the dags you want.
>
> This is as simple as substituting a hash and equality function.
>
> To whit: Actual compilers do it this way.
>
> So i'm entirely unsure why there is such an argument that it hard or
> impossible, or even strange.
>
> It is in fact quite easy, the same way GCC has had the VN pass that
> produces expression DAG output, and had it used to  code hoisting, to do
> PRE, to do folding, to do whatever.  It has been used for all of these
> thing.
>
> Some of these use a more standard  VN definition of equivalence that is
> useful for redundancy elimination.
> Some of them use one that is meant for folding (and would be illegal to
> use for straight redundancy elimination).
>
> If you want to build a pass that basically does the same thing, it seems
> silly, but feel free!
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160831/44117848/attachment.html>