Displaying 20 results from an estimated 10000 matches similar to: "Particular type of loop optimization"
2016 Feb 03
3
Particular type of loop optimization
Thanks Mehdi,
I tried to use this, but some debug information can be lost in these
optimizations.
I need write in the source file to insert information before the loops, and
in
some cases, I'm writing after the loop header.
Please, take a look:
int foo1 (int *a, int *b, int n) {
int i, s= 0;
for (i = 0; i < n; i++) {
s = s * a[i];
}
for (i = 0; i < n; i++) {
2016 Feb 03
2
Particular type of loop optimization
Hi Mats,
so, my overall goal is to insert annotations in the original C
source. I produce these annotations after analyzing the bytecode that
clangs gives me for that source. Thus, I need debugging information in
the bytecode file. What are these annotations? They are comments
relating variables which are pointers and their sizes, as program
symbols. For instance, if I have a program like
2019 Jun 30
2
Information Loss of Array Type in Function Interface in IR Generated by Clang
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
2019 Jun 30
2
Information Loss of Array Type in Function Interface in IR Generated by Clang
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:
...
2015 Jul 16
4
[LLVMdev] Improving loop vectorizer support for loops with a volatile iteration variable
----- Original Message -----
> From: "Hal Finkel" <hfinkel at anl.gov>
> To: "Chandler Carruth" <chandlerc at google.com>
> Cc: llvmdev at cs.uiuc.edu
> Sent: Thursday, July 16, 2015 1:58:02 AM
> Subject: Re: [LLVMdev] Improving loop vectorizer support for loops
> with a volatile iteration variable
> ----- Original Message -----
> >
2015 Aug 13
2
[LLVMdev] Improving loop vectorizer support for loops with a volatile iteration variable
Hi Gerolf,
I think we have several (perhaps separable) issues here:
1. Do we have a canonical form for loops, preserved through the optimizer, that allows naturally-constructed loop nests to remain separable?
2. Do we forbid non-lowering transformations that turn vectorizable loops into non-vectorizable loops?
3. How do we detect cases where transformations cause a negative answer to either
2013 Jun 18
2
[LLVMdev] -indvars issues?
It seems there is no -enable-iv-rewrite now in llvm3.2, and it suggest
-enable-load-pre, but it still does not work.
So, how to active the transform?
--
View this message in context: http://llvm.1065342.n5.nabble.com/indvars-issues-tp4646p58587.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.
2019 Nov 10
2
Reassociation is blocking a vectorization
Hi Devs,
I am looking at the bug
https://bugs.llvm.org/show_bug.cgi?id=43953
and found that following piece of ir
%arrayidx = getelementptr inbounds float, float* %Vec0, i64 %idxprom
%0 = load float, float* %arrayidx, align 4, !tbaa !2
%arrayidx2 = getelementptr inbounds float, float* %Vec1, i64 %idxprom
%1 = load float, float* %arrayidx2, align 4, !tbaa !2
%sub = fsub fast float %0, %1
2017 Aug 08
2
[ScalarEvolution][SCEV] no-wrap flags dependent on order of getSCEV() calls
Hi all,
I'm looking into resolving a FIXME in the LoopDataPrefetch (and
FalkorMarkStridedAccesses) pass by marking both of these passes as
preserving the ScalarEvolution analysis. Unfortunately, when this
change is made, LSR will generate different code. One of the root
causes seems to be that SCEV will return different nsw/nuw flags for the
same Value, depending on what order the
2014 Feb 19
2
[LLVMdev] better code for IV
Hi Andrew,
The issue below refers to LSR, so I'll appreciate your feedback. It also refers to instruction combining and might impact backends other than X86, so if you know of others that might be interested you are more than welcome to add them.
Thanks, Anat
_____________________________________________
From: Shemer, Anat
Sent: Tuesday, February 18, 2014 15:07
To: 'llvmdev at
2015 Aug 22
3
loop unrolling introduces conditional branch
Hi, Mehdi,
For example, I have this very simple source code:
void foo( int n, int array_x[])
{
for (int i=0; i < n; i++)
array_x[i] = i;
}
After I use "clang -emit-llvm -o bc_from_clang.bc -c try.cc", I get
bc_from_clang.bc. With my code (using LLVM IRbuilder API), I get
bc_from_api.bc. Attachment please find thse two files. I also past the IR
here.
2015 Aug 22
2
loop unrolling introduces conditional branch
Thanks for your point that out. I just add DataLayout in my code such as
"mod->setDataLayout("e-m:e-i64:64-f80:128-n8:16:32:64-S128");", still no
luck.
I'm really confused about this. Do I need to add more passes before
-loop-unroll?
On Sat, Aug 22, 2015 at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> On Aug 22, 2015, at 7:27 AM, Xiangyang
2011 Aug 19
3
[LLVMdev] Why int variable get promoted to i64
Hi, all
I found in some cases the int variable get promoted to i64,
although I think it should i32. I use the online demo
(http://llvm.org/demo). And below is the test case.
------------- test case -------------
int test(int x[], int y[], int n) {
int i = 0;
int sum = 0;
for ( ; i < n; i++) {
sum += x[i] * y[i];
}
return sum;
}
-------------------------------------
No
2013 Feb 05
1
[LLVMdev] Vectorizing global struct pointers
On 5 February 2013 17:28, Nadav Rotem <nrotem at apple.com> wrote:
> We insert runtime overlap checks only for unidentified objects. The
> problem here is that the vectorizer thinks that A,B,C are all pointers to
> the same array, so it gives up. If A,B,C were different arrays then it
> could have used runtime checks.
>
Yes, that is exactly the code that creates the
2013 Feb 05
3
[LLVMdev] Vectorizing global struct pointers
Hi all,
One of the reasons the Livermore Loops couldn't be vectorized is that it
was using global structures to hold the arrays. Today, I'm investigating
why is that so and how to fix it.
My investigation brought me
to LoopVectorizationLegality::canVectorizeMemory():
if (WriteObjects.count(*it)) {
DEBUG(dbgs() << "LV: Found a possible read/write reorder:"
2017 May 19
4
memcmp code fragment
Hi,
Look at the following code:
Look at the following C code seqence:
unsigned char mainGtU ( unsigned int i1,
unsigned int i2,
unsigned char* block)
{
unsigned char c1, c2;
c1 = block[i1]; c2 = block[i2];
if (c1 != c2) return (c1 > c2);
i1++; i2++;
c1 = block[i1]; c2 = block[i2];
if (c1 != c2) return (c1 > c2);
i1++; i2++;
..
..
2016 Feb 11
3
Expected constant simplification not happening
Hi
the appended IR code does not optimize to my liking :)
this is the interesting part in x86_64, that got produced via clang -Os:
---
movq -16(%r12), %rax
movl -4(%rax), %ecx
andl $2298949, %ecx ## imm = 0x231445
cmpq $2298949, (%rax,%rcx) ## imm = 0x231445
leaq 8(%rax,%rcx), %rax
cmovneq %r15, %rax
movl $2298949, %esi ## imm = 0x231445
movq %r12, %rdi
movq %r14,
2013 Jun 25
2
[LLVMdev] SimplifyIndVar looses nsw flags
Hello,
I'm using LLVM to reason about memory safety of programs. One goal is to
prove that certain array accesses are always safe.
Currently, one of these proofs fails because of a missing no-signed-wrap
(nsw) flag. I found that it has been "lost" during the SimplifyIndVar pass.
Here's the example:
int foo(int a[]) {
int sum = 0;
for (int i = 0; i < 1000; ++i)
2015 Apr 25
3
[LLVMdev] alias analysis on llvm internal globals
Hi
I have this program in which fooBuf can only take on NULL or the
address of local_fooBuf, and fooBuf and local_fooBuf have scope of the
foo function.
Therefore there is no way for the fooPtr argument to alias with
fooBuf. However, LLVM basicaa and globalsmodref-aa say the 2 pointers
may alias.
I am thinking whether i should implement a limited form of point-to
alias on the fooBuf pointer in
2015 Aug 22
2
loop unrolling introduces conditional branch
Hi,
I just tried llvm-3.8 (LLVM SVN Repository). With this version, -fno-rtti
can help me to compile my code and -irce can help me to do a better job for
loop unrolling. However, I still have one question. If I use Clang to
compile a piece of c++ code to .bc and then use 'opt -loop-rotate
-loop-unroll -irce', I can get what I want. I mean, there is no conditional
branch at the end of each