similar to: [LLVMdev] wrong code generation for memcpy function in SROA optimization pass

On 11/11/2015 8:53 AM, Hal Finkel wrote: > > SROA seems to be doing a number of things here. What about if we prevented SROA from generating multiple slices splitting volatile accesses? There might be a significant difference between that and something like this test (test/Transforms/SROA/basictest.ll): > > define i32 @test6() { > ; CHECK-LABEL: @test6( > ; CHECK: alloca i32 >

On 11/10/2015 1:07 PM, Joerg Sonnenberger via llvm-dev wrote: > On Tue, Nov 10, 2015 at 10:41:06AM -0600, Krzysztof Parzyszek via llvm-dev wrote: >> I have a customer testcase where SROA splits a volatile memcpy and we end up >> generating bad code[1]. While this looks like a bug, simply preventing SROA >> from splitting volatile memory intrinsics causes basictest.ll for SROA

Hi, I have a customer testcase where SROA splits a volatile memcpy and we end up generating bad code[1]. While this looks like a bug, simply preventing SROA from splitting volatile memory intrinsics causes basictest.ll for SROA to fail. Not only that, but it also seems like handling of volatile memory transfers was done with some intent. What are the design decisions in SROA regarding

On 11/11/2015 9:36 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> >> >> Yeah, the remark about devices I made in my post was a result of a >> "last-minute" thought to add some rationale. It doesn't actually >> apply >> to SROA, since there are no devices that are

On 11/11/2015 9:28 AM, Chandler Carruth wrote: > So, here is the model that LLVM is using: a volatile memcpy is lowered > to a loop of loads and stores of indeterminate width. As such, splitting > a memcpy is always valid. > > If we want a very specific load and store width for volatile accesses, I > think that the frontend should generate concrete loads and stores of a > type

Hi, For the following case, $ cat bad1.ll target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32-S64" define internal void @test(i32 %v) { entry: %tmp = alloca i32, align 4 store i32 %v, i32* %tmp, align 4 %0 = bitcast i32* %tmp to <2 x i8>* %1 = load <2 x i8>* %0, align 4 ret void } I

Introduction ============ `SROA' is an early stage pass running at the very beginning of the pipeline in `-O{1,2,3}'. Greg Bedwell's report from his DExTer tool shows SROA on function as one of the major culprits of Debug Info loss. With debugify-each partially done I tried testing this on the amalgamated sqlite source. The steps are as follows: ,---- | # generate

On Mon, Sep 24, 2012 at 3:41 AM, David Tweed <david.tweed at arm.com> wrote: > Just a note that the following new regressions have started to show up on > ARM/Linux: > Thanks for letting me know! I know that there is one serious bug that would impact in BE system. I should have that fixed today, along with a crasher. I would appreciate help tracking down any issues once the one I

> On May 30, 2018, at 8:37 AM, Anast Gramm <anastasis.gramm2 at gmail.com> wrote: > > Introduction > ============ > > `SROA' is an early stage pass running at the very beginning of the > pipeline in `-O{1,2,3}'. Greg Bedwell's report from his DExTer tool > shows SROA on function as one of the major culprits of Debug Info > loss. > > With

After a lot of testing and help from Duncan, Benjamin, Joerg and others, I think the new SROA is ready for some broader testing. I've fixed all the crashers and miscompiles that Duncan and Joerg have been able to find (although I'm sure there are a few left I'll tackle when there are reports), and the LNT numbers look *really* good. Here is the latest LNT run we got by flipping it on

I can't think of a better way to do this, so I think it's ok. I also submitted a complementary patch on llvm-commits clarifying volatile semantics. -Andy On Jan 28, 2013, at 8:54 AM, Arnaud A. de Grandmaison <arnaud.allarddegrandmaison at parrot.com> wrote: > Hi All, > > In the language reference manual, the access behavior of the memcpy, > memmove and memset

Hi, I am working to improve SROA to generate better code when a method has a struct in its arguments. I would appreciate it if I could have any suggestions or comments on how I can best proceed with this optimization. * Problem * I observed that LLVM often generates redundant instructions around glibc’s istreambuf_iterator. The problem comes from the scalar replacement (SROA) for methods with an

Adding llvm-dev to this thread as this is probably worth wider discussion. See the original patch email below. If you're sending just code-related comments, consider dropping llvm-dev. On Mon, Aug 20, 2012 at 3:37 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > Hello all! I've been busy working on a somewhat larger patch than usual, > and Duncan indicated I should get

I'm having an issue where SROA will throw away no-alias information on some loads after inlining, because the loads are derived from a store to an alloca which can be removed after inlining. The pointers that were originally stored into the alloca do *not *have any aliasing information - the only context that allowed me to assert aliasing was that the inlined-function guaranteed it to be so.

On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >> Hi, >> >> I'm trying to get AA results for two pointers, but it seems that AA >> cannot look though a memcpy. For example: >> >> define dso_local spir_func void @fun() { >> entry: >> ; Store an address of `var' >> %var = alloca i32, align 4 >>

I would like to get feedback from the community on how I can speed up the compilation of a function that has one huge basic block consisting of over 150K instructions. It takes about 10 minutes for clang to produce the object file and the function that is taking up the majority of the time is LoadAndStorePromoter::run, which is called when SROA is run: // Otherwise, we have mixed loads and

Hi All, In the language reference manual, the access behavior of the memcpy, memmove and memset intrinsics is not well defined with respect to the volatile flag. The LRM even states that "it is unwise to depend on it". This forces optimization passes to be conservatively correct and prevent optimizations. A very simple example of this is : $ cat test.c #include <stdint.h>

On Thu, May 15, 2014 at 9:31 AM, Philip Reames <listmail at philipreames.com>wrote: > On 05/14/2014 06:02 PM, Akira Hatanaka wrote: > > I would like to get feedback from the community on how I can speed up > the compilation of a function that has one huge basic block consisting of > over 150K instructions. It takes about 10 minutes for clang to produce the > object file

Hi! I created a bug report (https://llvm.org/bugs/show_bug.cgi?id=23712) for this failure but then I realized that my approach may be wrong. The following D source contains a lazy variable: void bar(lazy bool val) { val(); } The lazy variable val is translated to a delegate. The signature and the first IR lines are: define void @_D7opover23barFLbZv({ i8*, i1 (i8*)* } %val_arg) #0 {

FWIW, I've raised the LICM issue here: https://bugs.llvm.org/show_bug.cgi?id=37682 On 31 May 2018 at 13:28, Anast Gramm <anastasis.gramm2 at gmail.com> wrote: > Thanks, > These are very helpful. > > As I understand it, SROA and LICM render some variables > "useless" by optimizing the code to not use them. Hence we can't debug > them. > >