similar to: Loop Strength Reduction Pass Does Not Work for Some Varialbles Related to Induction Variables

Dear Momchil, Thanks a lot for your prompt reply and kindly suggestion. The code will truly lead to some automatic unrolling with GCC and increase the number of operations in the assembly code. However, I am focus on the the IR optimization and the calculation of the array element offest, which may need multiplication if the IR instruction GEP is lowered to arithmetic operations. The

Dear David, Thanks for your prompt reply! Sure, I can implement a AST visitor to go through the AST to get the information but I just wonder whether there is any other way to let Clang do so. What I am considering is how to let the generated IR looks like below, which some tools realize: define dso_local i32 @_Z1fPii([51 x i32]* %A, i32 %x) local_unnamed_addr #0 !dbg !7 { entry: ...

Dear all, Hi! Recently, I notice a situation where I cannot infer the size of the outermost dimension of array in the function interface. To concretely depict the problem, I show the C source code and the generated IR code at the end. The array size of A[] is 51 but this information is lost in the generated IR. How can I maintain such information in IR? Should I set some argument for

Dear all, I write a new LoopPass which wants to use passes including LoopInfoWrapperPass, ScalarEvolutionWrapperPass and LoopAccessLegacyAnalysis. Therefore, I implement the following code based on LLVM 9.0.0: ===================================================================== bool LoopInformationCollect::runOnLoop(Loop *L, LPPassManager &) { auto &SE =

Dear all, Hi! I noticed an interesting situation when using getUnsignedRange and getSignedRange of SCEV for URem instruction. Here is an example with 2 IR instructions: %rem.lhs.trunc = trunc i32 %i15.082 to i8 --> getUnsignedRange --> [1,50) %rem81 = urem i8 %rem.lhs.trunc, 3 --> getUnsignedRange --> [-47,50) The problems are: 1) From my

Dear all, Hi! I encounter an interesting assertion failure when implementing my Pass, which is defined with the member functions shown below: ======================My Pass====================================== bool MYPass::runOnModule(Module &M) { for (auto &F : M) { SE = &getAnalysis<ScalarEvolutionWrapperPass>(F).getSE(); ......

Hi all, I got a interesting problem when calling getNumOperands() of CallInst. For example, call void @_Z2f2PA100_i([100 x i32]* nonnull %arraydecay) If I use getNumOperands(), it will return 2. However, if I use getCalledFunction()->getNumParams(), it will return 1. According to the IR, I think the number of operands of the call instruction should be 1. I

I've actually got an implementation of this as an arbitrary precision integer extension that I've written up an RFC for (but not submitted). Below is my copy/pasted RFC (again, not reviewed, but I DO have an implementation of it that I need to prepare for review). I suspect my implementation will do what you need out of it. Its actually more significant than just adding a normal

Hello, So, I have this testcase: void f(int n, int x[]) { if (n < 0) return; int a[n]; for (int i = 0; i < n; i++) a[i] = x[n - i - 1]; for (int i = 0; i < n; i++) x[i] = a[i] + 1; } that, compiled with -O1/-Os for AArch64 and X86, generates machine code, which fails to properly restore the stack pointer upon function return.

My 2 pennies is braces add unnecessary clutter and impair readability when used on a *single-line* statement. I count comments, that are on their own line as statement(s). For example: BAD: if (cond) // Comment foo(); GOOD: if (cond) { // Comment foo(); } BAD: if (cond) { foo(); // Comment } GOOD: if (cond) foo(); // Comment BAD: if (cond) for(;;) foo() GOOD: if (cond)

Hi Devs, debug info emitted by llvm does not contain DW_AT_Location for Formal parameter if it is an aggregate like below case 1) aggregate contain more than 4 homogeneous and size more than 128 bits i.e. typedef struct{ int a,b,c,d,e; }mystruct; void foo(mystruct ms){ } 2) aggregate contain hetrogeneous type and size more than 128 bits. i.e. typedef struct{ int a,b; float c,d,e; }mystruct; void

Hi Manish, Thanks for the patch, I'll check and commit. cheers, --renato PS: Patches are normally sent to llvm-commit list, unless they require a lot of discussion. On 15 January 2013 14:52, Manish Verma <manish.avtaar at gmail.com> wrote: > Hi, > > Transform/LoopStrengthReduction/post-inc-icmpzero.ll was failing for > clang-native-arm-cortex-a9 build-bot configuration.

Hi Renato, Thanks! I will make sure the patches are posted to the correct mailing list. Manish On Tue, Jan 15, 2013 at 3:04 PM, Renato Golin Linaro < renato.golin at linaro.org> wrote: > Hi Manish, > > Thanks for the patch, I'll check and commit. > > cheers, > --renato > > PS: Patches are normally sent to llvm-commit list, unless they require a > lot of

Did this conversation reach a conclusion? My ad hoc tally says that a slight majority of the responders preferred to fully brace statements and no one wanted to totally eliminate braces. The technical arguments for fully braced statements were 1) it's considered a slightly safer coding style and 2) commit diffs with fully braced statements may be slightly more to the point. I didn't

Hi, Transform/LoopStrengthReduction/post-inc-icmpzero.ll was failing for clang-native-arm-cortex-a9 build-bot configuration. The reason for the failure was the test was using hardcoded names. The attached patch fixes this failure by replacing the hard-coded variables names with pattern-matched variable names. I have checked that the test pass after applying the patch. Could somebody please

On Wed, 2012-02-08 at 17:26 -0800, Chris Lattner wrote: > On Feb 7, 2012, at 12:10 PM, Hal Finkel wrote: > >>> 1. "Target Data" for vectorization - I think that in order to improve > >>> the vectorization quality, the vectorizer will need more information > >>> about the target. This information could be provided in the form of a > >>>

Hello Momchil, (CC’ing more people that could correct me if I’m wrong) Thanks for looking into this. More answers below: > On 9 Apr 2018, at 17:57, Momchil Velikov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > So, I have this testcase: > > void f(int n, int x[]) { > if (n < 0) > return; > > int a[n]; >

Hi, I am trying to locate the passes run by clang/opt when it is passed the option -O3. Can someone point me where to look at? Eventually, I want to turn off just the LoopStrengthReduction pass in the -O3 set of default passes. Thanks, Best Regards, Nitish -------------- next part -------------- An HTML attachment was scrubbed... URL:

> cmpq %rbx, %r14 > jne .LBB0_1 > > LLVM can perform compare-jump fusion, it already does in certain cases, but > not in the case above. We can remove the cmp above if we were to perform > the following transformation: Do you mean branch-fusion (https://en.wikichip.org/wiki/macro-operation_fusion)? Is there any more limitation why these two or not fused? > -----Original

I'll note that reading along I haven't found any of the proposed changes particularly worthwhile.  I'm also not strongly opposed to any of them - I just don't care - but I certainly haven't been convinced there's any clear benefit to be had by changing our current policy. Philip On 6/22/20 1:44 PM, Chris Lattner via llvm-dev wrote: > For those who don’t like it, is