search for: calixt

...hat goal, as many passes were not respectful of that contract, but as of 3667d87a33d3c8d4072a41fd84bb880c59347dc0, https://reviews.llvm .org/D80916 has been merged in master and the check is active, which should prevent further regression on that topic. Thanks a lot to @foad, @jdoerfert, @fhahn, @calixte (and others I'm sorry to forgot) for their help during the reviews. On Fri, Jun 12, 2020 at 11:24 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Thu, Jun 11, 2020 at 8:42 AM Serge Guelton via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi f...

...not > respectful of that contract, but as > of 3667d87a33d3c8d4072a41fd84bb880c59347dc0, https://reviews.llvm > .org/D80916 has been merged in master and the check is active, which > should prevent further regression on that topic. > > Thanks a lot to @foad, @jdoerfert, @fhahn, @calixte (and others I'm sorry > to forgot) for their help during the reviews. > > > This is great news! > > Some years ago, we did some experiments on whether we could develop more > fixed-point optimization within LLVM's pipeline. This was not the only > impediment we iden...

I've just wasted a day chasing my tail because of subtleties introduced to handle the optionality of the DataLayout. I would like to never do this again. =] We now have this attached to the Module with just a flimsy faked-up pass to keep APIs consistent. So, is there any problem with beginning down the path of: 1) Synthesizing a "default" boring DataLayout for all modules that

Hi folks, Per the documentation[0], whenever an LLVM pass doesn't modify the IR it's run on, it should return `false`--it's okay to return `true` if no change happen, just less optimal. In the New PM area, this is generally translated into a `PreservedAnalyses::all()`. https://reviews.llvm.org/D80916 provides an `EXPENSIVE_CHECK` that computes a hash of the IR before and after the