I don't know of a way to do it from the command-line, but if you're willing to change the IR, you can add the optsize (for -Os) or minsize (for -Oz) IR attribute to the function you're compiling. On Fri, Sep 2, 2016 at 5:59 AM, Bruce Hoult via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Idle question, if anyone is reading still ... how do you get llc to do -Os > or -Oz? The docs say the argument must be an integer, and anything other > than 0..3 is rejected. (in fact .. bug report ... 10 thru 39 are also > silently accepted as are 100 thru 399 etc) > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160902/8bfd8450/attachment.html>
Hi, Back to the original question - undef * 0 = 0 may have some issues. Consider the evaluation of the expression undef * (1 - 1) (1) undef * (1 - 1) ~> undef * 0 ~> 0 (as suggested) (2) undef * (1 - 1) ~> undef * 1 + undef * (-1) ~> undef + undef ~> undef and now the evaluation of undef can be some other value than 0. Thus it does not follow the law of distribution of multiplication over addition property and the algebraic transformations are ambiguous. Similarly associativity of boolean algebra is also violated as follows: undef & a & !a (1) ~> (undef & a) & !a ~> undef & !a ~> undef (2) ~> undef (a & !a) ~> undef & 0 ~> 0 Is there any clear set of rules how LLVM handles such cases? Best Regards, soham> I don't know of a way to do it from the command-line, but if you're > willing > to change the IR, you can add the optsize (for -Os) or minsize (for -Oz) > IR > attribute to the function you're compiling. > > On Fri, Sep 2, 2016 at 5:59 AM, Bruce Hoult via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Idle question, if anyone is reading still ... how do you get llc to do >> -Os >> or -Oz? The docs say the argument must be an integer, and anything other >> than 0..3 is rejected. (in fact .. bug report ... 10 thru 39 are also >> silently accepted as are 100 thru 399 etc) >> >> >
I think you're looking at "undef" the wrong way. "Undef" is not a value, "undef" is a placeholder where the compiler can choose an arbitrary value at every occurence of "undef". You could choose different values for "undef" in your example, so the law of distribution holds: undef * (1 - 1) ~> undef * 1 + undef * (-1) ~> 0 * 1 + 0 * (-1) ~> 0 + 0 = 0 or even undef * (1 - 1) ~> undef * 1 + undef * (-1) ~> undef + undef ~> undef (same as yours so far) ~> 0 Here's a blog post which describes "undef" in more detail, also describing a case where it inhibits optimization: http://www.playingwithpointers.com/problem-with-undef.html On 2016-09-12 09:36, Soham Chakraborty via llvm-dev wrote:> Hi, > > Back to the original question - undef * 0 = 0 may have some issues. > > Consider the evaluation of the expression undef * (1 - 1) > > (1) undef * (1 - 1) ~> undef * 0 ~> 0 (as suggested) > > (2) undef * (1 - 1) ~> undef * 1 + undef * (-1) ~> undef + undef ~> > undef > and now the evaluation of undef can be some other value than 0. > > Thus it does not follow the law of distribution of multiplication over > addition property and the algebraic transformations are ambiguous. > > Similarly associativity of boolean algebra is also violated as follows: > > undef & a & !a > (1) ~> (undef & a) & !a ~> undef & !a ~> undef > (2) ~> undef (a & !a) ~> undef & 0 ~> 0 > > Is there any clear set of rules how LLVM handles such cases? > > Best Regards, > soham > > >> I don't know of a way to do it from the command-line, but if you're >> willing >> to change the IR, you can add the optsize (for -Os) or minsize (for >> -Oz) >> IR >> attribute to the function you're compiling. >> >> On Fri, Sep 2, 2016 at 5:59 AM, Bruce Hoult via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Idle question, if anyone is reading still ... how do you get llc to >>> do >>> -Os >>> or -Oz? The docs say the argument must be an integer, and anything >>> other >>> than 0..3 is rejected. (in fact .. bug report ... 10 thru 39 are also >>> silently accepted as are 100 thru 399 etc) >>> >>> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi Soham, You're right that in LLVM IR arithmetic (with the current definition of `undef`) is not distributive. You can't replace `A * (B + C)` with `A * B + A * C` in general, since (exactly as you said) for A `undef`, B = `1`, C = `-1` the former always computes `0` while the latter computes `undef`. This is fundamentally because replacing `A * (B + C)` with `A * B + A * C` increases the number of uses of `A` (which is `undef`), and thus injects more behavior into the program. I _think_ going from `A * B + A * C` to `A * (B + C)` is okay though. Here is a simpler example of a similar issue: `X - X` is not equivalent `0`, in that `0` cannot be replaced with `X - X`, even though `X - X` can be folded to `0`. -- Sanjoy