search for: misoptimisation

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?)

...e 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 shouldn't break any out of tree backend, however, it may cause misoptimisation if the backend dev do not activate these opcodes via setOperationAction and rely on them for some of their optimizations. I would like to gather some feedback about moving forward with that as it can impact a wide range of users. So, feedback ? Thanks in advance for your answers, Amaury Séchet...

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

...e 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 shouldn't break any out of tree backend, however, it may cause > misoptimisation if the backend dev do not activate these opcodes via > setOperationAction and rely on them for some of their optimizations. Thanks for heads up, this will impact the OR1K backend. Is there any guidance for migrating to U*O/*CARRY? -- whitequark

在 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

...the loop by around 20%, with a corresponding decrease in performance. My somewhat long-winded point is that I’m not convinced that InstCombine is doing sufficient reasoning when it moves instructions between basic blocks to determine that the moves actually make sense. In this benchmark, this one misoptimisation offset all of the other gains from InstCombine and simply disabling it gave us better code. I don’t know how many other examples of this there are, but it would probably be good to have an InstCombine that ran on single basic blocks (or sequences with trivial flow control) and did folding that was...

...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 shouldn't break any out of tree backend, however, it may cause > misoptimisation if the backend dev do not activate these opcodes via > setOperationAction and rely on them for some of their optimizations. > > I would like to gather some feedback about moving forward with that as > it can impact a wide range of users. > > So, feedback ? > > Thanks in...

On Tue, Jan 24, 2012 at 08:36:17AM -0800, Esperanza de Escobar wrote: > 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. No, it is the core of the issue. Standard C gives the compiler certain

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