similar to: Optimizing functions using logical operators

On Thu, Jun 30, 2016 at 6:09 PM, Carlos Liam via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Consider this C code: > > #include <stdbool.h> > > bool func(int n1, int n2, bool b) { > bool greater = n1 > n2; > if (greater && b) { > if (n1 == n2) { > return false; // unreachable > } >

On Thu, Jun 30, 2016 at 6:45 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 30, 2016 at 6:09 PM, Carlos Liam via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> Consider this C code: >> >> #include <stdbool.h> >> >> bool func(int n1, int n2, bool b) { >>

PropagateEquality in gvn.cpp However, if you are going to do it, remember the goal is to make the code simpler and easier, not just pile on to the current mess to catch more cases :) On Mon, Jul 4, 2016, 7:51 AM Carlos Liam <carlos at aarzee.me> wrote: > Where would I look to change the equality propagation? > > > - CL > > On Jun 30, 2016, at 11:45 PM, Daniel Berlin

It's going to be really hard to do something sane in the current infrastructure. Its possible, but it would also be slow. You would have to go looking at uses of variables compared in predicates in PropagateEquality and if the uses appear in a comparison that is dominated by the true or false edge of the existing predicate, see if it tells you something about the dominated one. On Mon, Jul

The current gvn equality propagation is not powerful enough to get this because it doesn't try to infer values in predicates based on other predicates, so it never realizes a>b -> a !=b in a useful way. It otherwise would get this On Thu, Jun 30, 2016, 7:41 PM Sean Silva <chisophugis at gmail.com> wrote: > On Thu, Jun 30, 2016 at 6:45 PM, Daniel Berlin via llvm-dev <

Sure On Mon, Jul 4, 2016, 9:40 AM Carlos Liam <carlos at aarzee.me> wrote: > It looks like there's already something similar in PropagateEquality which > eg X >= Y == true and replaces X < Y == false, which is somewhat similar - > could I base an addition off of that? > > > - CL > > On Jul 3, 2016, at 7:13 PM, Daniel Berlin <dberlin at dberlin.org>

On Jun 14, 2012, at 3:54 PM, Walter Landry wrote: > Hello Everyone, > > I thought you might be interested in some C++ expression template > benchmarks I have done. > > http://www.wlandry.net/Projects/FTensor#Benchmarks > > Clang's performance was mixed. It optimized the expression template > code just as well as the code that unrolled the expressions by hand,

On Wed, Oct 12, 2016 at 10:53 AM, Hal Finkel <hfinkel at anl.gov> wrote: > I don't think that Clang/LLVM uses it by default on x86_64. If you're using -Ofast, however, that would explain it. I recommend looking at -O3 vs -O0 and make sure those are the same. -Ofast enables -ffast-math, which can legitimately cause differences. > The following tests pass at "-O3" and

Duncan, What is the situation with -Ofast in dragonegg 3.4? Are we now enabling all of the same optimizations for that case as are done in clang when it is passed -Ofast? Thanks in advance for any clarification. Jack

On Thu, Feb 22, 2018 at 9:53 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 02/22/2018 09:34 PM, Stepan Salenikovich wrote: > > Its unexpected because the decoder continues to output all samples > > of -32768 even when the microphone input is silence or near silence, so > > I would expect the decoded values to be at or near 0. > > Oh, if the output is

On 14 October 2016 at 15:50, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > These 3 tests are passing with the following configurations: > -O3 -ffp-contract=off > -O3 -ffp-contract=on > -O0 -ffp-contract=off > -O0 -ffp-contract=on > > They are not passing at: > -Ofast -ffp-contract=on > -Ofast -ffp-contract=off Let's separate completely FP-contract and

On Jun 15, 2012, at 9:16 AM, Douglas Gregor wrote: > On Jun 14, 2012, at 3:54 PM, Walter Landry wrote: >> Hello Everyone, >> >> I thought you might be interested in some C++ expression template >> benchmarks I have done. >> >> http://www.wlandry.net/Projects/FTensor#Benchmarks >> >> Clang's performance was mixed. It optimized the

On Wed, Oct 12, 2016 at 10:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias

On Fri, Oct 14, 2016 at 10:50 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Sebastian Pop" <sebpop.llvm at gmail.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, "Sebastian Paul Pop" <s.pop at samsung.com>,

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmp_IntToFP_Cst, there are these lines: // Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero) return nullptr; Why check for positive

Hi Mehdi, You are right – modifying the Function Attributes pass to mark “main” as norecurse would break the C standard (unless it has a similar statement regarding “main” that the C++ standard has – I cannot find it), so that’s a no-go. Looks like there was an attempt to bypass library calls in the Function Attributes pass for the purpose of detecting norecurse functions:

I think the conceptual issues have largely been sorted out, it is mostly that it is *much* harder to deduce norecurse than it might seem like superficially. On Mon, Mar 21, 2016 at 4:02 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Mar 21, 2016, at 3:57 PM, Sanjin Sijaric via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > GlobalOpt may not

On Thu, Feb 22, 2018 at 8:34 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Stepan, > > I would need more information to be able to investigate further. It's > legal for the decoder to output -32768, so it would be good if you could > explain how this is unexpected. Its unexpected because the decoder continues to output all samples of -32768 even when the

The test case that you added in this revision fails on several of the power buildbots (for example, http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20127) and also when I build it locally: FAIL: Clang :: CodeGenCXX/main-norecurse.cpp (2951 of 27722) ******************** TEST 'Clang :: CodeGenCXX/main-norecurse.cpp' FAILED ******************** Script: --

Hi all, I?m trying to plot this data N M W I 10 106 II 124 484 III 321 874 IV 777 1140 V 896 996 VI 1706 1250 VII 635 433 VIII 1437 654 IX 693 333 X 1343 624 XI 1221 611 XII 25 15 XIII 3 XIV 7 8 So that in de Y axis will be the level (qualitative data) and in the X axis will be M and W variables. So x axis will be wwith a lenght between 0 and 2000. I would like to plot a line with M and other