similar to: [SROA][DebugInfo][GSoC] Testing SROA on amalgamated sqlite source

> > > `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. > > The methodology I used is with the opt-bisect-limit option on clang, so it's not strictly the case that the results presented

> 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

> > is in the business of deciding, but it does score it as a difference > because it now, at no point, sees the expression "first" evaluate to a > value of 5, or "total" to a value of 8 which it did previously. From the > source-level debugging experience, the variables now just get updated > between iterations. > Obviously should've been 7 for that

> That is good to hear / expected, since we went though great lengths to ensure that SROA preserves variable debug info. > > Have you looked at the location-less phi instructions? > Does empty mean line 0 or do you mean they have no debug location whatsoever? Most of them have line 0, only 12 are locationless. > Are they empty for good reasons or does it look more like an

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. > >

SROA optimization pass did some optimizations and transforms for memcpy function,such as ld/st operations.When someone has written down code like size>sizeof(dest) in memcpy(*dest,*src,size), there was much likely a wrong code generation.for example,considered as such testcase: int main() { char ch; short sh = 0x1234; memcpy(&ch,&sh,2); printf("ch=0x%02x\n",ch); } At

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

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

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

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

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

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.

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

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 {