Displaying 20 results from an estimated 33 matches for "loopidiomrecognizer".
Did you mean:
loopidiomrecognize
2012 Oct 27
2
[LLVMdev] [llvm-commits] [llvm] r166875 - in /llvm/trunk: lib/Transforms/Scalar/LoopIdiomRecognize.cpp test/Transforms/LoopIdiom/basic.ll
On 27.10.2012, at 18:24, Benjamin Kramer <benny.kra at gmail.com> wrote:
>
> On 27.10.2012, at 18:15, Sean Silva <silvas at purdue.edu> wrote:
>
>> How does this affect freestanding implementations?
>
> This transform is disabled with -fno-builtin or -ffreestanding.
Thinking a bit more about this, it looks like the way -ffreestanding is implemented in clang is
2016 Feb 08
2
LoopIdiomRegognize vs Preserved
Hi,
I'm having problems with the LoopIdiomRegognizer crashing on me with
An asserting value handle still pointed to this value!
UNREACHABLE executed at ../lib/IR/Value.cpp:695!
If I remove
AU.addPreserved<LoopInfoWrapperPass>();
or
AU.addPreserved<AAResultsWrapperPass>();
everything goes well.
The C-code triggering this is
void foo(int a[10][10])
{
int i, j,
2018 Jun 02
2
LoopIdiomRecognize is not recognizing the ctpop idiom
Hello.
Could you please tell me why am I not able to recognize (with LLVM built from the SVN
code in Apr 25, 2018) the LLVM IR intrinsic ctpop (described at
https://llvm.org/docs/LangRef.html#llvm-ctpop-intrinsic) in the following program:
int PopCnt_Simple(int x) {
int numBits = 0;
int i;
//for (i = 0; i < 32; i++) {
for (i = 0; x !=
2016 Feb 09
2
LoopIdiomRegognize vs Preserved
Hi Haicheng,
Originally I ran into this on our out-of-tree target but I managed to
reproduce the crash on X86 as well now:
build-all/bin/opt -S -sroa -loop-rotate -loop-deletion -licm
-loop-idiom ../llvm/bugpoint-reduced-simplified.i8+.ll
gives:
While deleting: void %
An asserting value handle still pointed to this value!
UNREACHABLE executed at ../lib/IR/Value.cpp:696!
0 opt
2014 Mar 11
4
[LLVMdev] Memcpy / Memset for address spaces >= 256
Hi,
SelectionDAGBuilder doesn't know how to lower a Memcpy and Memset if one
of the pointer operands have an address space >= 256. This is
understandable since the libc's memcpy / memset don't work for these
address spaces. However, both Clang (when copying a struct) and some
optimization passes (LoopIdiomRecognize, MemCpyOpt) can emit memcpy /
memset for these address
2020 Jul 17
4
Allowed operations for passes that report "no change"
I’m digging through a build failure [1], and it looks like the loop idiom recognizer adds some instructions [2], and then removes them again [3]. I don’t understand why yet, but the LegacyPassManager detects that the structural hash of the function has changed, and complains that the pass didn’t correctly report that it changed the function [4] (even though materially, it didn’t).
This raises a
2017 Jan 05
2
WinEH funclet coloring in computeLoopSafetyInfo
I've been looking at compilation time issues in the LICM pass, and it looks to me like colorEHFunclets() is probably being called a lot more often than it needs to be for functions that have Windows EH personality functions. For one thing, the funclet coloring is happening when computeLoopSafetyInfo() is called from LoopIdiomRecognize and LoopUnswitch but those passes don't use the
2016 Feb 10
2
LoopIdiomRegognize vs Preserved
Hi,
On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote:
> Thank you, Mikael. I can reproduce what you saw and am looking into it.
Great!
> Just curious, why do you run loop-deletion before licm and loop-idiom?
As part of our internal testing we use Csmith to generate C-programs and
then we run the compiler with random generated compiler flags on that
input.
This bug was
2011 Jan 12
0
[LLVMdev] opt, loopidiom pass and compiling system libraries
It seems LoopIdiomRecognizer pass recognizes one loop inside memSet as memset and replaces it with memset intrinsic, which might then be converted into memset call, resulting in infinite recursion.
There is parameter -fno-builtins to prevent this, BUT when executing opt as "standalone", this parameter cannot be give...
2017 Nov 09
2
CFG normalization: avoiding `br i1 false`
Hi,
I was looking at Rust programs which are poorly optimized by LLVM, and
one occasional factor is that LLVM allows for long-lived `br i1 false`
instructions.
The problem is that if a propagation pass discovers the condition of a
branch, the branch itself will not be eliminated until a SimpllfyCfg
pass is reached, of which there are few in the pipeline.
One example is
2019 Aug 13
2
Loop optimization
Thanks a lot for your help.
Indeed if I compile with -OZ the loop gets replaced with something like this:
if ( *v3 < 0 )
v4 = 0;
Is there a reason why it does not get applied with O3 ?
I mean this a huge improvement to the loop.
-----Original Message-----
From: Doerfert, Johannes [mailto:jdoerfert at anl.gov]
Sent: Dienstag, 13. August 2019 19:13
To: llvm-dev at lists.llvm.org; Garba
2012 Nov 02
3
[LLVMdev] DependenceAnalysis and PR14241
Hey Preston,
I wanted to let you know that we found a really serious problem with
DependenceAnalysis in PR14241. In summary, DA seems to have a baked-in
assumption that the base pointer of the GEPs it inspects are loop
invariant. It appears to only do analysis on the subscripts.
This is especially important for LLVM because C++ code (compiled
through Clang) very frequently expresses loops as
2019 Aug 13
2
Loop optimization
Hi,
I was wondering if there is an optimization pass in LLVM or Polly that can optimize this given loop:
int main(int argc, char* argv[]) {
char s = 0;
// Loop is setting s = argv[1][0];
for (int i=0; i<argv[1][0]; i++) {
s++;
}
printf("s = %c\n", s);
return 0;
}
2014 Mar 12
2
[LLVMdev] Memcpy / Memset for address spaces >= 256
Hi David,
sorry for sending you the mail two times, I forgot to send to the list
the first time.
On 2014-03-12 09:48, David Chisnall wrote:
> I have some patches that automatically expand all memcpy and similar
> if the operands are not in AS 0. I think this is probably not quite
> the right approach though, and we should be asking the back end for
> the function that does a memcpy
2018 Apr 23
0
Conditional analysis before inliner
I probably wouldn't worry about the cost of LoopInfo; it's relatively
cheap to compute. But if you're really concerned, you can run your pass
after a pass which preserves LoopInfo (so it's free because it was
already computed). Or you can stick your code into an existing pass
which requires LoopInfo anyway, like LoopIdiomRecognize.
-Eli
On 4/23/2018 3:37 PM, Anom LLVM
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++;
..
..
2018 Apr 19
5
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
On Thu, Apr 19, 2018 at 2:53 PM Tim Northover <t.p.northover at gmail.com>
wrote:
> On 19 April 2018 at 22:36, Manoj Gupta via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I was looking around for the cases where AddrSpace !=0 are checked. Seems
> > like there are a bunch of optimizations that will fail to apply for non
> zero
> > address spaces.
>
2018 Apr 28
0
[cfe-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang
On Thu, Apr 19, 2018 at 3:56 PM, Manoj Gupta via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> My understanding is we only want to disable the optimizations regarding
> undefined behavior
> related to null pointer deference optimizations. And address space checks
> will end up
> disabling more optimizations than needed.
[Repeating what others have already mentioned on this
2014 Aug 28
4
[LLVMdev] How to tell whether a GlobalValue is user-defined
>> Agreed. If ld64 can drop support for .o produced by the old gcc that
>> would be awesome. Failing that, what is really needed is
> Because of static archives, the linker has to support old .o files for quite a while. I also don’t know when clang starting getting this right.
r123585 (Jan 16 17:19:34 2011) I think.
> Also, this seems like linker complexity for a very
2018 Apr 23
2
Conditional analysis before inliner
Thanks for the answer Eli.
I think I was a little too vague in my question. The program has the
following structure:
void foo() {
bar();
}
void bar() {
for (..) {
__builtin_compute()
}
}
We would like to use scalar evolution + loopinfowrapperpass inside
instcombine only if __builtin_compute is present. instcombine can convert
the loop into a single builtin ie.
void bar() {