search for: misoptimises

On Thu, 9 Aug 2018 at 22:59, Kim Gräsman <kim.grasman at gmail.com> wrote: > > Thanks all for pitching in to help! > > On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall <sam.mccall at gmail.com> wrote: > > > > Obviously if there really is something illegal here we should fix it in > > LLVM, but it looks like this warning is a false positive (anyone disagree?)

These opcodes have been deprecated about a year ago, but still in use in various backend. In https://reviews.llvm.org/D47422 I would like to change the behavior of the backend to not enable the use of these opcodes by default. The opcode remains usable by any backend that wish to use them, but that should limit the situation where newer backend just use them as they are enabled by default. This

Author of the problematic code here. Thanks everyone, and sorry to have caused difficulty! Obviously if there really is something illegal here we should fix it in LLVM, but it looks like this warning is a false positive (anyone disagree?) Still if there's a simple source-level workaround, or we can suppress the warning with a #pragma, I'd be happy to do that. GCC 4.9.3 is a supported

On 2018-05-30 16:57, Amaury Séchet via llvm-dev wrote: > These opcodes have been deprecated about a year ago, but still in use > in various backend. > > In https://reviews.llvm.org/D47422 I would like to change the behavior > of the backend to not enable the use of these opcodes by default. The > opcode remains usable by any backend that wish to use them, but that > should

在 2018-08-10 06:20, Kim Gräsman 写道: > On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely <jwakely.gcc at gmail.com> > wrote: >> >> If GCC 4.9.3 thinks there's an aliasing violation it might >> misoptimise. It doesn't matter if it's right or not, it matters if it >> treats the code as undefined or not. >> >> And apparently GCC does think

On 11 Sep 2017, at 21:32, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As a data point for this, I did a quick walkthrough of the top-level of instcombine, and one thing that stuck out to me is that it tries to sink instructions in certain "easy" scenarios. That doesn't fit a graph rewriting system. The sinking in instcombine is not always a win. We

For targets where ADDCARRY and SUBCARRY are legal, would it make sense to expand ADDC/UADDO/ADDE/etc. into ADDCARRY (and same for sub)? Are there plans to deprecate UADDO/USUBO in favor of ADDCARRY/SUBCARRY? -Krzysztof On 5/30/2018 11:57 AM, Amaury Séchet via llvm-dev wrote: > These opcodes have been deprecated about a year ago, but still in use in > various backend. > > In

...g you'll find other support board posts > asking "Why is my code suddenly crashing after upgrading Xcode?" Your code is buggy. Stop justifying it by saying that GCC doesn't utilise optimisation potential. It has been proven over and over again, that half of the cases where GCC misoptimises code turned out to be completely broken assumptions by the code in question. Never versions of GCC tended to expose new bugs. It's not a problem in the compiler. I wouldn't be surprised if you get the same behavior with a recent GCC, too. > You can measure its damage pretty significantl...

No one is arguing that there aren't ABI specs or LLVM design guidelines that say that unaligned accesses "should not", "could not" or "aren't guaranteed to" work, because it's besides the point. The point is that unaligned 32-bit loads and stores *work in practice* on every single ARM device Apple has ever manufactured. I'm not a hardware person, but

On 09/11/2017 10:50 AM, Sean Silva via llvm-dev wrote: > > > On Mon, Sep 11, 2017 at 8:14 AM, Daniel Neilson via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > Just thinking out loud…. I’m really not familiar with the vast > majority of what instcombine does, so please excuse me if my > naiveté is too